From bobby@sharedrealm.com Thu Apr 1 01:08:09 2010 Return-Path: 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 6CB613A6A4A for ; Thu, 1 Apr 2010 01:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 o7mzmmaeuYE3 for ; Thu, 1 Apr 2010 01:08:08 -0700 (PDT) Received: from mail.neoawareness.com (ns2.sharedrealm.com [IPv6:2001:470:1f05:4f4::13]) by core3.amsl.com (Postfix) with ESMTP id 711F33A672E for ; Thu, 1 Apr 2010 01:08:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[10.200.0.30]) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from ) id 1NxFS9-0003zv-Rx for vwrap@ietf.org; Thu, 01 Apr 2010 01:08:37 -0700 From: "Robert G. Jakabosky" To: vwrap@ietf.org Date: Thu, 1 Apr 2010 00:08:33 -0800 User-Agent: KMail/1.9.10 References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> In-Reply-To: <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201004010108.34044.bobby@sharedrealm.com> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bobby@sharedrealm.com X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 08:08:09 -0000 The only use cases I can see for a version field are: 1. A new more compact binary encoding (i.e. remove closing tags, remove 'k' tags, variable-length encoded sizes, support for compression codecs). 2. A new basic/container type is added to LLSD. Case 1 would make the new version completely incompatible with old readers. In this case the sender could downgrade to the old format if the reader rejected a 2.0 format. Case 2 would require some type of extension tag in version 1.0 to allow old readers to even skip/ignore the new type. This case would also require changes to the JSON & XML encoding formats. It might not be possible to downgrade the LLSD content in this case. XML readers can ignore unknown tags, but what about JSON readers? LLSD uses all the JSON types, there isn't anyway to add an extension that will be ignored by 1.0 readers. Since LLSD already has three encoding formats defined, there will need to be a way (MIME-type/Content-Type) to identify which format was used to encode a LLSD message and a way for the client & server to negotiate which formats they accept. So I see no reason for adding a version tag to the binary format, when a new MIME-type will provide the same functionality. -- Robert G. Jakabosky From dwl@us.ibm.com Thu Apr 1 09:26:41 2010 Return-Path: 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 0A6533A67F6; Thu, 1 Apr 2010 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 MbVOURGIXuv0; Thu, 1 Apr 2010 09:26:40 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id BFE0E3A69CC; Thu, 1 Apr 2010 09:26:04 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o31GHh99004925; Thu, 1 Apr 2010 12:17:43 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o31GQa2f168358; Thu, 1 Apr 2010 12:26:36 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o31GQap3003412; Thu, 1 Apr 2010 12:26:36 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o31GQaep003379; Thu, 1 Apr 2010 12:26:36 -0400 In-Reply-To: References: To: John Hurliman MIME-Version: 1.0 X-KeepSent: B874EBBC:BF65C513-852576F8:0059C798; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 1 Apr 2010 12:26:30 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/01/2010 12:26:35, Serialize complete at 04/01/2010 12:26:35 Content-Type: multipart/alternative; boundary="=_alternative 005A5122852576F8_=" Cc: vwrap@ietf.org, vwrap-bounces@ietf.org Subject: Re: [vwrap] Parsing of invalid LLSD elements in XML X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:26:41 -0000 This is a multipart message in MIME format. --=_alternative 005A5122852576F8_= Content-Type: text/plain; charset="US-ASCII" I *think* we are talking about a very special case here. A badly formed uuid, or date, element is a funny case because it's not a default, and we can *tell* its badly formed. For the other cases, the defaulting is fine and how we approach protocol jitter. But.. having defined uuid and date quite precisely a badly formatted uuid isn't protocol jitter, its a baddly formed uuid. (And, having done the exercise of defining uuid and date very tightly, we're in the position where we have to be very careful changing what's permitted as valid serializations for those specific elements, and I'd argue we're pretty well stuck with upwards compatible changes, or defining a "long-uuid" if we need long ones. The highly bound nature of these elements imposes constraints on us.) - David ~Zah --=_alternative 005A5122852576F8_= Content-Type: text/html; charset="US-ASCII"
I *think* we are talking about a very special case here.  A badly formed uuid, or date, element is a funny case because it's not a default, and we can *tell* its badly formed.
For the other cases, the defaulting is  fine and how we approach protocol jitter. But.. having defined uuid and date quite precisely a badly formatted uuid isn't protocol jitter, its a baddly formed uuid. (And, having done the exercise of defining uuid and date very tightly, we're in the position where we have to be very careful changing what's permitted as valid serializations for those
specific elements, and I'd argue we're pretty well stuck with upwards compatible changes, or defining a "long-uuid" if we need long ones. The highly bound nature of these elements imposes constraints on us.)

- David
~Zah
--=_alternative 005A5122852576F8_=-- From markl@lindenlab.com Thu Apr 1 11:17:58 2010 Return-Path: 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 A068F3A6A10 for ; Thu, 1 Apr 2010 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 OO8hlACalD6Y for ; Thu, 1 Apr 2010 11:17:57 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 38E6D3A69B3 for ; Thu, 1 Apr 2010 11:17:57 -0700 (PDT) Received: by pwi10 with SMTP id 10so1286303pwi.31 for ; Thu, 01 Apr 2010 11:18:27 -0700 (PDT) Received: by 10.140.251.9 with SMTP id y9mr857693rvh.276.1270145905681; Thu, 01 Apr 2010 11:18:25 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id g14sm1643202rvb.23.2010.04.01.11.18.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 11:18:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: <201003291545.41626.bobby@sharedrealm.com> Date: Thu, 1 Apr 2010 11:18:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E19A702-810C-4F48-B21F-4DC24C30EDD8@lindenlab.com> References: <201003291545.41626.bobby@sharedrealm.com> To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] identifying a malformed LLSD request with HTTP binding X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:17:58 -0000 On Mar 29, 2010, at 3:45 PM, Robert G. Jakabosky wrote: On Monday 29, Meadhbh Hamrick wrote: > so assuming there is consensus to reject malformed LLSD messages, > allow me to ask, how do we signal the fact that a server receiving a > HTTP request believes the message was malformed? >=20 > reply with a 400 : Bad Request ? This looks right to me. It should probably be called out in Foundation. = However, since we aren't likely to mandate any particular action in = response to a 400, I'd suggest we don't define what the response body = should contain. If an implementation wants to provide details, it can, = but clients shouldn't expect that the response body with a 400 status = will be LLSD, or even given. It might very well be text or HTML. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Thu Apr 1 11:37:54 2010 Return-Path: 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 BFD0F3A697A for ; Thu, 1 Apr 2010 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 wumRqjr4Sk-O for ; Thu, 1 Apr 2010 11:37:54 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0448E3A6944 for ; Thu, 1 Apr 2010 11:37:53 -0700 (PDT) Received: by pwi10 with SMTP id 10so1306193pwi.31 for ; Thu, 01 Apr 2010 11:38:22 -0700 (PDT) Received: by 10.141.125.8 with SMTP id c8mr907663rvn.180.1270147101940; Thu, 01 Apr 2010 11:38:21 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id o38sm3270305rvp.21.2010.04.01.11.38.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 11:38:21 -0700 (PDT) From: Mark Lentczner Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-1--217878584 Date: Thu, 1 Apr 2010 11:38:17 -0700 In-Reply-To: To: vwrap References: <201003282129.59068.bobby@sharedrealm.com> Message-Id: X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] type-system : eliminate closing tags for collections in binary serialization? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:37:54 -0000 --Apple-Mail-1--217878584 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think I'm seeing some general consensus on this thread: 1) The extra tags (closing and key tags) are superfluous, but, no one = seems very worried about squeezing bytes out. 2) Mal-formed serializations (of all types) should be rejected, not = "fixed up" 3) Mismatched object-counts and closing tags should be defined as = mal-formed, as should missing key tags. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com --Apple-Mail-1--217878584 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think I'm seeing some general consensus on this thread:

1) = The extra tags (closing and key tags) are superfluous, but, no one = seems very worried about squeezing bytes out.
2) Mal-formed = serializations (of all types) should be rejected, not "fixed = up"
3) Mismatched object-counts and closing tags should be = defined as mal-formed, as should missing key = tags.

- Mark

Mark = Lentczner
Sr. Systems Architect
Technology = Integration
Linden Lab


Zero Linden




= --Apple-Mail-1--217878584-- From markl@lindenlab.com Thu Apr 1 13:21:17 2010 Return-Path: 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 3FD8F3A6950 for ; Thu, 1 Apr 2010 13:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 8dywXAKRKdaP for ; Thu, 1 Apr 2010 13:21:16 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 433973A685D for ; Thu, 1 Apr 2010 13:21:03 -0700 (PDT) Received: by gwj15 with SMTP id 15so1027490gwj.31 for ; Thu, 01 Apr 2010 13:21:32 -0700 (PDT) Received: by 10.150.180.12 with SMTP id c12mr1915220ybf.144.1270153291743; Thu, 01 Apr 2010 13:21:31 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id 21sm1979038yxe.39.2010.04.01.13.21.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 13:21:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB5FBCB3@rrsmsx506.amr.corp.intel.com> Date: Thu, 1 Apr 2010 13:21:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81A71295-EB0A-4F87-9F97-85CC5F7F4CCE@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB5FB69D@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB5FB75C@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB5FBCB3@rrsmsx506.amr.corp.intel.com> To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] type-system : binary elements in JSON serializations X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:21:17 -0000 There are several interrelated issues here: 1) There appears to be consensus that the JSON serialization of binary = values should be as a JSON string value containing the Base64 encoded = version of the binary data. (Rather than the current array of small = integers.) However, at a receiving end, JSON would provide no way to distinguish a = LLSD binary value and an LLSD string value that happened to be decodable = as Base64. For example, the JSON string "NoteWell" could be the Base64 = encoding of the octets 0x36.8b.5e.59.e9.65 In the usage model of LLSD, the receiving end knows what it wants and = reads a value as the type it needs. (This is why all the conversion = rules are defined as how to read an X when given a Y in the data.) In = order to allow a program wanting binary to read it when transmitted via = JSON, we'd need to define a default conversion to Binary from String.=20 2) Should we add a conversion to Binary from String? It would be defined = as Base64 decode the string if valid, otherwise result in the default = Binary value (zero octets). All the other conversions are symmetric. Adding a conversion to String = from Binary implies that there are cases where the receiving end expects = a string, but there was a Binary value on the wire (this cannot happen = with JSON encoding). I cannot come up with a use case for this = conversion. Perhaps if there were a programming environment where binary = values are natively handled as Base64 encoded strings? (This is the = rationale for the other conversions: Such as environments that don't = distinguish between numbers and strings...) There is also a possible temptation to keep people from: The intention = of such a string from binary conversion is NOT to circumvent LLSD's = commitment to all text being terms of Unicode strings. Text encoded in = some encoding should NOT be sent as Binary, relying on automatic Base64 = encoding to get it into some environment via Strings if needed, only to = be decoded on the other side. The right thing to do is to send the = Unicode string as an LLSD String, transcoding as needed by the chosen = serialization method. Admittedly this worry might over blown, but I have = seen programmers "just try anything until it works for some broken case" = when it comes to character encoding errors. I originally left out the = Binary<->String conversions to ensure no one could ever go there! 3) Should we add the reverse conversion: to String from Binary?. It = would be simply Base64 encoding the binary values. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Thu Apr 1 15:20:06 2010 Return-Path: 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 5DDB23A68B8 for ; Thu, 1 Apr 2010 15:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.083 X-Spam-Level: * X-Spam-Status: No, score=1.083 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, URI_HEX=0.368] 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 whnB5bNNL6Td for ; Thu, 1 Apr 2010 15:20:05 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 487E93A68AA for ; Thu, 1 Apr 2010 15:20:05 -0700 (PDT) Received: by ywh38 with SMTP id 38so1118700ywh.29 for ; Thu, 01 Apr 2010 15:20:34 -0700 (PDT) Received: by 10.101.2.18 with SMTP id e18mr1245944ani.193.1270160434297; Thu, 01 Apr 2010 15:20:34 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id 39sm2014689yxd.6.2010.04.01.15.20.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 15:20:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: <4BAA59BB.90300@gmail.com> Date: Thu, 1 Apr 2010 15:20:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B2F17AC-9A1B-4D29-B57B-496CC3CD2F0E@lindenlab.com> References: <180093C2-AC6E-435B-8AD5-A58B81CCD9FB@lindenlab.com> <4BAA59BB.90300@gmail.com> To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] Notes ... 9) query arguments to LLIDL X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:20:06 -0000 Mark Lentczner wrote: > **9) No one had concerns or issues with the addition of query = arguments to LLIDL... On Mar 24, 2010, at 11:28 AM, Dzonatas Sol wrote: > Just to clarify from IETF session chat to make sure we are on the same = page: >=20 > This is an acceptable standard query: /Resource/Path/ > This is not standard, but an acceptable customization: = /Resource/Path/?encode=3Dtext&format=3Djson I don't have the context of the chat session, but, no, this doesn't = speak to what I was getting at. Let me see if I can clarify: The VWRAP foundation doesn't ever look at the form of URLs used to = access resources. They are either "well known" (as in published), or = received in response to a seed-capability request. In all cases, the = entity using such a URL to access a resource never looks at the = structure of the URL (except to perhaps verify that it doesn't resolve = to localhost.) Any of these URLs would be acceptable: = http://example.com/Resource/Path/f5771b22-239d-4497-9575-55494863c1ac = http://example.com/f5771b22-239d-4497-9575-55494863c1ac?r=3Dresource/path http://example.com/YWdlbnQ9OTkmb3A9cHJvZmlsZSZkZXRhaWw9Mw=3D=3D = http://path.resource.example.com/f5771b22-239d-4497-9575-55494863c1ac = http://f5771b22-239d-4497-9575-55494863c1ac.example.com/resource-path In other words, the provider of the resource is free to choose ANY = scheme they like for associating URLs and resources. This is one of the = essential tenets of the REST thesis. > We shouldn't expect the customization to be supported across the board = on all implementations. Instead, from feedback and various reads, we = should make use of the Content-Type: field where possible instead of = path arguments. >=20 > For example: Content-Type: text/json > Or: Content-Type: application/xml+llsd Correct. The second example URL you gave is clearly wrong in intent: The = format negotiation is intended to be handled in the transport layer, not = at the resource layer. When the transport is HTTP, HTTP has a well = defined and widely implemented content negotiation system and that = should be the sole method of content selection. > Other operation arguments are probably best found in the body of the = query rather than the header. > Please clarify further is this what was not intended. The LLIDL addition of support for query arguments enables a declaration = of a resource that tells the client of that resource that some (or all) = of the data supplied with the invocation should be added to the = otherwise opaque URL for a resource. Without this addition, all client = supplied data with a request would have to be in the request body. Consider: %% thing/description << { name: string, id: uuid, mod_time: date, thing/comments: uri = } =09 %% thing/comments ?? { from: int, to: int } << [ { n: int, when: date, who: uuid, text: string }, ... ] The intent of this interface is that the client should take the URI = returned for thing/comments in response to invoking a thing/description = URL, and then append the desired range of comments to that URI. So, for example, imagine the client has a URL for a given = thing/description: http://example.com/gizmo-1231415144592/desc It invokes that and gets back (in JSON): { "name": "Widget", "id": "f5771b22-239d-4497-9575-55494863c1ac", "mod_time": "2001-04-01T23:03:00Z", "thing/comments": = "http://comments.example.com/gizmo-1231415144592" } To get comments 1 through 25, it would then construct and invoke this = URL: http://comments.example.com/gizmo-1231415144592?from=3D1&to=3D25 Nothing in VWRAP currently uses this style, and judging from past = discussion there are many who would strongly discourage using it. = Defining how to add the query args is tricky, full of corner cases, and = would be a fair bit of work, especially if the base URI already has = query args! That said, backends seem to often use this style of URL, in part because = it enables caching based on some of the client's arguments. Because = there was desire to use a single IDL language for specifying REST like = interfaces, we implemented the '??' feature of LLIDL here at Linden Lab. = It was my point that I think VWRAP implementors will find this feature = generally useful, even if not used directly by the standards, for the = same reasons as we did. Lastly, I was asking if implementors felt a similar need for being able = to define client supplied arguments that go into the path of a URL. = Inside of Linden Lab there is some desire for this, though less so than = the query argument declaration. Further, it is also less clear just how = much expressive power is needed for path arguments. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Thu Apr 1 15:35:12 2010 Return-Path: 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 7A7003A689D for ; Thu, 1 Apr 2010 15:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 EGVEp0fETig7 for ; Thu, 1 Apr 2010 15:35:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B7BD03A681B for ; Thu, 1 Apr 2010 15:35:08 -0700 (PDT) Received: by gwj15 with SMTP id 15so1100976gwj.31 for ; Thu, 01 Apr 2010 15:35:38 -0700 (PDT) Received: by 10.101.107.7 with SMTP id j7mr3582645anm.186.1270161337623; Thu, 01 Apr 2010 15:35:37 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id 7sm2038194yxd.8.2010.04.01.15.35.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 15:35:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: Date: Thu, 1 Apr 2010 15:35:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D274A4F-C6B7-44CA-B327-EA1E02C2A6E9@lindenlab.com> References: To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] Notes ... 6) LLIDL "event-like" resource X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:35:12 -0000 On Mar 30, 2010, at 5:45 PM, David W Levine wrote: > I'm leaning to saying "Keep LLIDL simple" and adding the simple event=20= > messages. We can then stick to prose for describing interaction=20 > patterns.=20 Agreed! I think we will come to the conclusion that we need to do the heavy = lifting of describing higher level interaction patterns that include = event subscription and notification. But any such description will need = a small event like transaction unit to build on, and that is what I = think is missing from LLIDL. I'm pretty sure that we can agree on what a description like this means: %% stoplight/update >> { active: bool, color: string, blink_rate: real } When bound to HTTP, this probably a POST with a request body, an no = response body is expected. How end-points of that resource class are bound, and if the binding is = per-object, or per-resource class (requiring an id within the payload), = and how such an event is transferred, will all be needed, but probably = not as part of LLIDL. Such interaction should either be in Foundation, = or a new draft: Event Subscription. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Thu Apr 1 15:51:26 2010 Return-Path: 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 3A9063A68E5 for ; Thu, 1 Apr 2010 15:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.968 X-Spam-Level: X-Spam-Status: No, score=0.968 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 rpn5RHI5jr5V for ; Thu, 1 Apr 2010 15:51:25 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 73F0F3A6877 for ; Thu, 1 Apr 2010 15:51:25 -0700 (PDT) Received: by gxk20 with SMTP id 20so1178102gxk.12 for ; Thu, 01 Apr 2010 15:51:54 -0700 (PDT) Received: by 10.100.244.24 with SMTP id r24mr3442818anh.216.1270162314339; Thu, 01 Apr 2010 15:51:54 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id 5sm445097yxd.35.2010.04.01.15.51.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 15:51:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: Date: Thu, 1 Apr 2010 15:51:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DA5BF47-FF62-4843-81D8-C354E36683E1@lindenlab.com> References: To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] Parsing of invalid LLSD elements in XML X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:51:26 -0000 On Apr 1, 2010, at 9:26 AM, David W Levine wrote: > I *think* we are talking about a very special case here. This seems at the core to me. We are asking about cases where the = serialization rules have been violated. If, for example, the uuid value = was correct but the closing uuid tag misspelled "", then XML = processing would have required that the whole XML document to be = rejected. Seems to me that the case of the text inside the uuid element = not conforming to the UUID syntax is the same: The entire LLSD value = should be rejected.=20 As for error reporting, I note that even though XML processing demands = that the whole document be rejected, parsers are still able to report = specific and helpful error messages at the receiving side. The same = should be true of LLSD processors. - Mark P.S.: Small bit of XML pedantry: On Mar 31, 2010, at 2:53 PM, Joshua Bell wrote: > ... this LLSD XML fragment (pretend it has the right prologue and = hence is well-formed XML): >=20 > > > test > this is not a uuid > > Actually, that is well-formed XML just as it sits. There is no = requirement for an XML prolog where XML doesn't mandate one. Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From trac@tools.ietf.org Thu Apr 1 15:55:49 2010 Return-Path: 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 15E863A68A3 for ; Thu, 1 Apr 2010 15:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.971 X-Spam-Level: X-Spam-Status: No, score=-99.971 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 HGWemA0RrZIN for ; Thu, 1 Apr 2010 15:55:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 66E343A681B for ; Thu, 1 Apr 2010 15:55:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxTJF-0004JH-Aw; Thu, 01 Apr 2010 15:56:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "vwrap issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: markl@lindenlab.com X-Trac-Project: vwrap Date: Thu, 01 Apr 2010 22:56:21 -0000 X-URL: http://tools.ietf.org/vwrap/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/vwrap/trac/ticket/19 Message-ID: <059.91a39a0ecf02b15549efb5e7051cada1@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: markl@lindenlab.com, vwrap@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: vwrap@ietf.org Subject: [vwrap] #19: handling binary serialization errors X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:55:49 -0000 #19: handling binary serialization errors --------------------------------+------------------------------------------- Reporter: markl@… | Owner: markl@… Type: enhancement | Status: new Priority: major | Milestone: Version: | Severity: - Keywords: TypeSystem | --------------------------------+------------------------------------------- To summarize, there are several possible mal-formed conditions in a binary serialized LLSD value: 1&2) The "object count" is inconsistent with the number of objects bound by the matching opening and closing tags for an array or map. (Original e-mail had these as two cases, too few and too many) 3) No matching closing tag is found for an array or map 4) Something other than a 'k' tag found where 'k' required in a map 5) A 'k' tag encountered either outside a map, or where a value is required in a map 6) Duplicate keys in a map From my (Mark) message about this: I believe that the mal-formed cases 1 through 5 should result in rejection. I can see no benefit to trying to repair what can only have been generated by incorrect code. (And yes, I lament the redundancy between the object counts and the closing tags.) Case 6 is tricker. I'm loathe to say that duplicate keys result in rejection, since that my difficult or awkward in some implementations. That would lead me to say "if there are duplicates, the result is undefined." But then I worry that people will do things like hide values from some implementations by relying on the priority they use. Which leads me to just say "last wins", though that too might be more awkward for some implementations. Still mulling…. -- Ticket URL: vwrap From trac@tools.ietf.org Thu Apr 1 15:58:09 2010 Return-Path: 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 9D3853A6877 for ; Thu, 1 Apr 2010 15:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.894 X-Spam-Level: X-Spam-Status: No, score=-100.894 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 CYH8PwMCGsOx for ; Thu, 1 Apr 2010 15:58:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 09FCD3A681B for ; Thu, 1 Apr 2010 15:58:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxTLW-0004LS-Bk; Thu, 01 Apr 2010 15:58:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "vwrap issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: markl@lindenlab.com X-Trac-Project: vwrap Date: Thu, 01 Apr 2010 22:58:42 -0000 X-URL: http://tools.ietf.org/vwrap/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/vwrap/trac/ticket/13#comment:1 Message-ID: <068.45a3339545706fc2413132dc847cbb1e@tools.ietf.org> References: <059.43579969f574abefe8791002f2971262@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <059.43579969f574abefe8791002f2971262@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: markl@lindenlab.com, vwrap@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: vwrap@ietf.org Subject: Re: [vwrap] #13: Binary serialization extension mechanism X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:58:09 -0000 #13: Binary serialization extension mechanism --------------------------------+------------------------------------------- Reporter: markl@… | Owner: markl@… Type: enhancement | Status: new Priority: major | Milestone: Version: | Severity: - Keywords: TypeSystem | --------------------------------+------------------------------------------- Comment(by markl@…): One option under discussion in the mailing list is adding an optional, leading version tag. -- Ticket URL: vwrap From trac@tools.ietf.org Thu Apr 1 16:01:04 2010 Return-Path: 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 5A7DF3A67FD for ; Thu, 1 Apr 2010 16:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.905 X-Spam-Level: X-Spam-Status: No, score=-100.905 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 F9RQbzdn9a9i for ; Thu, 1 Apr 2010 16:01:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3B5863A6812 for ; Thu, 1 Apr 2010 16:00:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxTNy-0004Rg-Dk; Thu, 01 Apr 2010 16:01:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "vwrap issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: markl@lindenlab.com X-Trac-Project: vwrap Date: Thu, 01 Apr 2010 23:01:14 -0000 X-URL: http://tools.ietf.org/vwrap/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/vwrap/trac/ticket/20 Message-ID: <059.ecb50b22a20eee19e8d2764c9ad0d808@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: markl@lindenlab.com, vwrap@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: vwrap@ietf.org Subject: [vwrap] #20: call out HTTP error to use when requests are malformed X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 23:01:04 -0000 #20: call out HTTP error to use when requests are malformed --------------------------------+------------------------------------------- Reporter: markl@… | Owner: markl@… Type: task | Status: new Priority: major | Milestone: Version: | Severity: - Keywords: Foundation | --------------------------------+------------------------------------------- Add language to the draft to the effect that: Signal the fact that a server receiving a HTTP request believes the message was malformed with a status of 400 : Bad Request -- Ticket URL: vwrap From carlo@alinoe.com Sat Apr 3 05:07:57 2010 Return-Path: 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 8B9223A67E7 for ; Sat, 3 Apr 2010 05:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 7sb47-fDcc0B for ; Sat, 3 Apr 2010 05:07:56 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 42F913A67AF for ; Sat, 3 Apr 2010 05:07:53 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100403120751.IXV29373.viefep12-int.chello.at@edge04.upcmail.net>; Sat, 3 Apr 2010 14:07:51 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id 107o1e01R0FlQed0407p1D; Sat, 03 Apr 2010 14:07:51 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Ny28i-0000dK-5v; Sat, 03 Apr 2010 14:07:48 +0200 Date: Sat, 3 Apr 2010 14:07:48 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20100403120748.GA2095@alinoe.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=SLkC287PFWo6d7eSEiSBB9255DBOWQ3bwOwHXJiyZoo= c=1 sm=0 a=FxBtSNRhrsMA:10 a=38zWk6xDZSoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=BjFOTwK7AAAA:8 a=ScFr9y0wSRo_75KCotYA:9 a=P8zYZgAz_d0ByWR5d0UA:7 a=QfgihwmvK-QROpkgNsBWsqSKyfsA:4 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Parsing of invalid LLSD elements in XML X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 12:07:57 -0000 I vote for 1). There is no way the receive can start to guess what the message means in this case, and therefore the whole thing should be escalated immediately, so whatever is wrong can be fixed. On Wed, Mar 31, 2010 at 02:53:25PM -0700, Joshua Bell wrote: > Mark Lentczner and I were discussing this issue earlier today offline, and I > wanted to recap it to the list. > > draft-hamrick-vwrap-type-system-00 does not define what should happen when > trying to parse this LLSD XML fragment (pretend it has the right prologue and > hence is well-formed XML): > > >      >         test >         this is not a uuid >      > > > There are at least three reasonable outcomes: > (1) Reject the payload entirely - the entire message should be rejected > (2) Produces a map; value associated with key "test" is a UUID of > 00000000-0000-0000-0000-000000000000 - which would be the result of converting > the string "this is not a uuid" to a UUID > (3) Produces a map; value associated with key "test" is the Undefined value > > (The map is, strictly speaking unnecessary, to the example, but it clarifies > the context in which #3 occurs) > > This is not confined to UUIDs; similar issues occur with Date and Binary types > in the XML serialization. The JSON serialization appears  "immune" to this spec > ambiguity because primitive types always end up as Boolean/String/Real/ > Undefined (in LLSD parlance); conversion to Integer/UUID/Date/URI/Binary can > only occur at the application level. The Binary serialization appears "immune" > to the spec ambiguity as well (possibly edge cases if a NaN or Infinity was > used for a Date?) > > Thoughts? > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Carlo Wood From john.hurliman@intel.com Mon Apr 5 11:39:47 2010 Return-Path: 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 C93FE3A67DA for ; Mon, 5 Apr 2010 11:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kuS6948JWnUS for ; Mon, 5 Apr 2010 11:39:47 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id ED4D33A68ED for ; Mon, 5 Apr 2010 11:39:45 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 05 Apr 2010 11:39:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,366,1267430400"; d="scan'208";a="555110060" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga002.fm.intel.com with ESMTP; 05 Apr 2010 11:39:38 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Mon, 5 Apr 2010 12:39:44 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Mon, 5 Apr 2010 12:39:41 -0600 Thread-Topic: Removing first name / last name assumptions? Thread-Index: AcrU71pG4LyUoRQFSYiBZ7wsggOU9g== Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 18:39:47 -0000 At the IETF77 meeting there was talk about removing the first name / last n= ame assumptions from the avatar identifier, but it looks like that conversa= tion didn't carry over to the mailing list. Does anyone know exactly which = I-Ds (and which sections) reference avatar identifiers as first_name+last_n= ame? John From ohmeadhbh@gmail.com Mon Apr 5 12:20:56 2010 Return-Path: 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 135063A6A59 for ; Mon, 5 Apr 2010 12:20:56 -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 BE9zk7Y4BwA7 for ; Mon, 5 Apr 2010 12:20:48 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 660583A6A4D for ; Mon, 5 Apr 2010 12:20:34 -0700 (PDT) Received: by qyk11 with SMTP id 11so4274472qyk.13 for ; Mon, 05 Apr 2010 12:20:29 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=h1NCwwCAWzvQg9WPhOm9u/F7W9BwhZg0hB9J4z/uom0=; b=QaREiAych9/PBkltljeAesbBjE+Luz6Zni94ZDmWRuP+ciT5j6HeLhfUjh+NjsThIw CESwuNGYD8c8F5gWS15vlGRoCR7ZqGXMgmSZaBgyJnSBEZJr5ZGEMZ8sGHfV0sc2yI+N RSB78QCYbYGXU8GZcQUkGBsyPeSaDG5y3r0yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=tQaNhFytVAy+DWzWEgPz72so3ZNDtCMyMFRRR/r9asMhLNFqAjNSO1X1GX0KeoaA9J ekiEUDCHkBRmoswLS2WECeSyQGcqJXZZreqpACcr5ulEjJfRKA2a3WZYMTWgmmGWRP07 kVnF1wYoYUCjm00DYe8x7z0SOzix/Wy1jpYLI= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 12:20:08 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 12:20:08 -0700 Received: by 10.229.242.3 with SMTP id lg3mr2124752qcb.102.1270495228546; Mon, 05 Apr 2010 12:20:28 -0700 (PDT) Message-ID: To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:20:56 -0000 i thought it did for a little bit basically here's the rub. sure, we can remove this bit of SL legacy from the protocol, but linden is unlikely to drop support for it from SL. so if it's removed from the protocol, then the first name / last name option for authentication (which is currently used by both SL and OpenSim) will need to be described in a proprietary extension to the auth spec. is this really what we want? do we really want to make it HARDER to access existing services run by organizations and individuals who are interested in making VWRAP a success? i still don't understand why keeping first name / last name as an OPTION is a problem for people. as far as i can tell, the people who prefer this course of action are morgaine and carlo, neither of which has indicated they will be implementing this specification. calling for the removal of other people's use cases is a bit rude. while this is not an effort to "bless" linden's Second Life model and legacy protocol, it is also not an effort to bury it. the current draft allows for EITHER an account identifier or an agent identifier to be used to identify a user for the purpose of authentication. if you want to use a single opaque identifier, use the account identifier. if you want to use a first name / last name, use the agent identifier. there is no requirement that an authentication service support both. the requirement is, that if you support the agent identifier, you use the map defined in the draft. as it stands now, the account identifier was intended to be used in conjunction with agent identifiers in case a user had multiple avatars attached to a single "account." maybe we could change it to this: ; agent identifier &agent_identifier =3D { name: [ string, ... ] } ; account identifier &account_identifier =3D { type : 'account', agents: [ &agent_identifier, ... ], } in this proposal, the data used to identify the user is an array. for systems like second life and OpenSim that want to use two names to identify users' agents can. systems that want to use a single account name (like an email address) can. the account identifier goes back to what it was supposed to be: a way for a user with multiple avatars to login with an account credential, giving a list of agent identifiers the authentication service should explicitly check for maintenance. so, to recap: a. please don't dis my use case. b. account identifiers actually serve a purpose other than just identifying an account, they communicate the client's interest int he maintenance state of the agents associated with the account. c. sure, i'm hip to dropping the last name / first name thing, but only if we can do something that supports our use case. (like doing a name array) d. servers shouldn't be REQUIRED to implement two string identifiers, but that being said, there are services that use them and it's probably a very good idea for clients to support this use case. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John w= rote: > At the IETF77 meeting there was talk about removing the first name / last= name assumptions from the avatar identifier, but it looks like that conver= sation didn't carry over to the mailing list. Does anyone know exactly whic= h I-Ds (and which sections) reference avatar identifiers as first_name+last= _name? > > John > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From morgaine.dinova@googlemail.com Mon Apr 5 12:33:57 2010 Return-Path: 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 63F5C3A6A69 for ; Mon, 5 Apr 2010 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 RxltXoWj757c for ; Mon, 5 Apr 2010 12:33:55 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 1A31D3A6A5B for ; Mon, 5 Apr 2010 12:33:53 -0700 (PDT) Received: by ewy24 with SMTP id 24so1307737ewy.13 for ; Mon, 05 Apr 2010 12:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Jbw/kU/SstCgQ6Xz1yp4E3tWwj8Wj+BWQafF8J/a1xM=; b=xgJtq0/OoZ5BGtpoCq4G0gQEMHSzrGNJS2jHmT8qpmJjdyqUzzeNj3hH/HFFl1Z+96 M/WQOwUrfltSntNfYMoZLlbb7xYhE09DoJSUeNngYh6Pg1EsNZJQpBwRMTdH/QNmnPNR ti45ypTrddY7SUYGrD1y9X3ad8EySFnS1+MtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rRFc9jQ4BcVFxRFlJOydiGfOONQdhwJrG5pnSvBlEZShaeNv5x3TomoSLx79W5ULwA q82RgRtSCWZsBXCkX9zINqI8Cd13o8fjp8M2y+7dULCIlo4qtH+scOxAdj9zEI4PW0R7 ThxFYj2kNg34xKUFwKpX7Bh45EyKhjs3yBVN0= MIME-Version: 1.0 Received: by 10.213.105.66 with HTTP; Mon, 5 Apr 2010 12:33:48 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> Date: Mon, 5 Apr 2010 20:33:48 +0100 Received: by 10.213.68.11 with SMTP id t11mr3181527ebi.98.1270496028782; Mon, 05 Apr 2010 12:33:48 -0700 (PDT) Message-ID: From: Morgaine To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=00c09ffb52007bf196048382685f Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:33:57 -0000 --00c09ffb52007bf196048382685f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 5, 2010 at 8:20 PM, Meadhbh Hamrick wrote: > > sure, we can remove this bit of SL legacy from the protocol, but > linden is unlikely to drop support for it from SL. so if it's removed > from the protocol, then the first name / last name option for > authentication (which is currently used by both SL and OpenSim) will > need to be described in a proprietary extension to the auth spec. Not so. All you need to do in SL is to parse the single composite name field containing embedded whitespace into component fields separated by the whitespace, reject any parsing that yields more than two component fields, and use these two component fields for SL's {firstname, lastname} tuple. Such local interpretations of the single name field should most definitely not be in the auth spec. Morgaine. ================================= On Mon, Apr 5, 2010 at 8:20 PM, Meadhbh Hamrick wrote: > i thought it did for a little bit > > basically here's the rub. > > sure, we can remove this bit of SL legacy from the protocol, but > linden is unlikely to drop support for it from SL. so if it's removed > from the protocol, then the first name / last name option for > authentication (which is currently used by both SL and OpenSim) will > need to be described in a proprietary extension to the auth spec. > > is this really what we want? > > do we really want to make it HARDER to access existing services run by > organizations and individuals who are interested in making VWRAP a > success? > > i still don't understand why keeping first name / last name as an > OPTION is a problem for people. as far as i can tell, the people who > prefer this course of action are morgaine and carlo, neither of which > has indicated they will be implementing this specification. > > calling for the removal of other people's use cases is a bit rude. > while this is not an effort to "bless" linden's Second Life model and > legacy protocol, it is also not an effort to bury it. > > the current draft allows for EITHER an account identifier or an agent > identifier to be used to identify a user for the purpose of > authentication. if you want to use a single opaque identifier, use the > account identifier. if you want to use a first name / last name, use > the agent identifier. there is no requirement that an authentication > service support both. the requirement is, that if you support the > agent identifier, you use the map defined in the draft. > > as it stands now, the account identifier was intended to be used in > conjunction with agent identifiers in case a user had multiple avatars > attached to a single "account." maybe we could change it to this: > > ; agent identifier > > &agent_identifier = { > name: [ string, ... ] > } > > ; account identifier > > &account_identifier = { > type : 'account', > agents: [ &agent_identifier, ... ], > } > > in this proposal, the data used to identify the user is an array. for > systems like second life and OpenSim that want to use two names to > identify users' agents can. systems that want to use a single account > name (like an email address) can. > > the account identifier goes back to what it was supposed to be: a way > for a user with multiple avatars to login with an account credential, > giving a list of agent identifiers the authentication service should > explicitly check for maintenance. > > so, to recap: > > a. please don't dis my use case. > b. account identifiers actually serve a purpose other than just > identifying an account, they communicate the client's interest int he > maintenance state of the agents associated with the account. > c. sure, i'm hip to dropping the last name / first name thing, but > only if we can do something that supports our use case. (like doing a > name array) > d. servers shouldn't be REQUIRED to implement two string identifiers, > but that being said, there are services that use them and it's > probably a very good idea for clients to support this use case. > > -cheers > -meadhbh > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > wrote: > > At the IETF77 meeting there was talk about removing the first name / last > name assumptions from the avatar identifier, but it looks like that > conversation didn't carry over to the mailing list. Does anyone know exactly > which I-Ds (and which sections) reference avatar identifiers as > first_name+last_name? > > > > John > > _______________________________________________ > > 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 > --00c09ffb52007bf196048382685f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 5, 2010 at 8:20 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:=

sure, we can remove this bit of SL legacy from the protocol, but
linden is unlikely to drop support for it from SL. so if it's removed from the protocol, then the first name / last name option for
authentication (which is currently used by both SL and OpenSim) will
need to be described in a proprietary extension to the auth spec.

Not so.

All you need to do in SL is to parse the single c= omposite name field containing embedded whitespace into component fields se= parated by the whitespace, reject any parsing that yields more than two com= ponent fields, and use these two component fields for SL's {firstname, = lastname} tuple.

Such local interpretations of the single name field should most definit= ely not be in the auth spec.


Morgaine.




=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

On Mon, Apr 5, 2010 at= 8:20 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
i thought it did = for a little bit

basically here's the rub.

sure, we can remove this bit of SL legacy from the protocol, but
linden is unlikely to drop support for it from SL. so if it's removed from the protocol, then the first name / last name option for
authentication (which is currently used by both SL and OpenSim) will
need to be described in a proprietary extension to the auth spec.

is this really what we want?

do we really want to make it HARDER to access existing services run by
organizations and individuals who are interested in making VWRAP a
success?

i still don't understand why keeping first name / last name as an
OPTION is a problem for people. as far as i can tell, the people who
prefer this course of action are morgaine and carlo, neither of which
has indicated they will be implementing this specification.

calling for the removal of other people's use cases is a bit rude.
while this is not an effort to "bless" linden's Second Life m= odel and
legacy protocol, it is also not an effort to bury it.

the current draft allows for EITHER an account identifier or an agent
identifier to be used to identify a user for the purpose of
authentication. if you want to use a single opaque identifier, use the
account identifier. if you want to use a first name / last name, use
the agent identifier. there is no requirement that an authentication
service support both. the requirement is, that if you support the
agent identifier, you use the map defined in the draft.

as it stands now, the account identifier was intended to be used in
conjunction with agent identifiers in case a user had multiple avatars
attached to a single "account." maybe we could change it to this:=

=A0; agent identifier

=A0&agent_identifier =3D {
=A0 =A0name: [ string, ... ]
=A0}

=A0; account identifier

=A0&account_identifier =3D {
=A0 =A0type : 'account',
=A0 =A0agents: [ &agent_identifier, ... ],
=A0}

in this proposal, the data used to identify the user is an array. for
systems like second life and OpenSim that want to use two names to
identify users' agents can. systems that want to use a single account name (like an email address) can.

the account identifier goes back to what it was supposed to be: a way
for a user with multiple avatars to login with an account credential,
giving a list of agent identifiers the authentication service should
explicitly check for maintenance.

so, to recap:

a. please don't dis my use case.
b. account identifiers actually serve a purpose other than just
identifying an account, they communicate the client's interest int he maintenance state of the agents associated with the account.
c. sure, i'm hip to dropping the last name / first name thing, but
only if we can do something that supports our use case. (like doing a
name array)
d. servers shouldn't be REQUIRED to implement two string identifiers, but that being said, there are services that use them and it's
probably a very good idea for clients to support this use case.

-cheers
-meadhbh

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



On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John <john.hurliman@intel.com> wrote:
> At the IETF77 meeting there was talk about removing the first name / l= ast name assumptions from the avatar identifier, but it looks like that con= versation didn't carry over to the mailing list. Does anyone know exact= ly which I-Ds (and which sections) reference avatar identifiers as first_na= me+last_name?
>
> John
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00c09ffb52007bf196048382685f-- From rbarnes@bbn.com Mon Apr 5 12:38:41 2010 Return-Path: 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 4EE4C3A6965 for ; Mon, 5 Apr 2010 12:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 olMcPsH18drg for ; Mon, 5 Apr 2010 12:38:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8A4CE3A6A27 for ; Mon, 5 Apr 2010 12:38:35 -0700 (PDT) Received: from [192.1.255.171] (port=54697 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nys80-000IYc-Cp; Mon, 05 Apr 2010 15:38:32 -0400 Message-Id: From: Richard Barnes To: Meadhbh Hamrick In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 15:38:31 -0400 References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.936) Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:38:41 -0000 Maybe I'm missing something here, but if you just had an opaque "client identifier" field where you could put an arbitrary name chosen by the provider, surely, then couldn't you just shove something like "Firstname Lastname" into that field? Also, wasn't there also some discussion in the meeting of separating display names from identifiers (as is common in IM and email systems)? That way you could have "Infinity Linden ". The only reason you would need to have a (Firstname, Lastname) pair in the *protocol* is if you expected a need for names to be used in that way interoperably. For example, my avatar walks into a new region operated by a party I've never met before, and the new region greets me by first name. Is that what you're thinking? (Even then, you could address with parsing, if this were not regarded as a critical use case. See Gmail's "first name extraction" in Inbox message summaries.) --Richard On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > i thought it did for a little bit > > basically here's the rub. > > sure, we can remove this bit of SL legacy from the protocol, but > linden is unlikely to drop support for it from SL. so if it's removed > from the protocol, then the first name / last name option for > authentication (which is currently used by both SL and OpenSim) will > need to be described in a proprietary extension to the auth spec. > > is this really what we want? > > do we really want to make it HARDER to access existing services run by > organizations and individuals who are interested in making VWRAP a > success? > > i still don't understand why keeping first name / last name as an > OPTION is a problem for people. as far as i can tell, the people who > prefer this course of action are morgaine and carlo, neither of which > has indicated they will be implementing this specification. > > calling for the removal of other people's use cases is a bit rude. > while this is not an effort to "bless" linden's Second Life model and > legacy protocol, it is also not an effort to bury it. > > the current draft allows for EITHER an account identifier or an agent > identifier to be used to identify a user for the purpose of > authentication. if you want to use a single opaque identifier, use the > account identifier. if you want to use a first name / last name, use > the agent identifier. there is no requirement that an authentication > service support both. the requirement is, that if you support the > agent identifier, you use the map defined in the draft. > > as it stands now, the account identifier was intended to be used in > conjunction with agent identifiers in case a user had multiple avatars > attached to a single "account." maybe we could change it to this: > > ; agent identifier > > &agent_identifier = { > name: [ string, ... ] > } > > ; account identifier > > &account_identifier = { > type : 'account', > agents: [ &agent_identifier, ... ], > } > > in this proposal, the data used to identify the user is an array. for > systems like second life and OpenSim that want to use two names to > identify users' agents can. systems that want to use a single account > name (like an email address) can. > > the account identifier goes back to what it was supposed to be: a way > for a user with multiple avatars to login with an account credential, > giving a list of agent identifiers the authentication service should > explicitly check for maintenance. > > so, to recap: > > a. please don't dis my use case. > b. account identifiers actually serve a purpose other than just > identifying an account, they communicate the client's interest int he > maintenance state of the agents associated with the account. > c. sure, i'm hip to dropping the last name / first name thing, but > only if we can do something that supports our use case. (like doing a > name array) > d. servers shouldn't be REQUIRED to implement two string identifiers, > but that being said, there are services that use them and it's > probably a very good idea for clients to support this use case. > > -cheers > -meadhbh > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > wrote: >> At the IETF77 meeting there was talk about removing the first >> name / last name assumptions from the avatar identifier, but it >> looks like that conversation didn't carry over to the mailing list. >> Does anyone know exactly which I-Ds (and which sections) reference >> avatar identifiers as first_name+last_name? >> >> John >> _______________________________________________ >> 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 From ohmeadhbh@gmail.com Mon Apr 5 12:47:07 2010 Return-Path: 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 AA6C73A696F for ; Mon, 5 Apr 2010 12:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rTqvOzYWtqUr for ; Mon, 5 Apr 2010 12:47:06 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 330723A67B7 for ; Mon, 5 Apr 2010 12:47:06 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1396227qwb.31 for ; Mon, 05 Apr 2010 12:47:04 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=v3gIO//ZFiGFvDT/LWKuGnsOVBkJ9mgXUbu6EBNxHHg=; b=tyzqAfyrAjMm2GV61Eot6wShKGws7cFpaly0SpRXGWw3HXsfQmU/zfWQyerQRr1k6E S6cs31ZSqgQxvjFgPgwtba9dARn6TmxKDN1aKHWYXopf6JYRXSfnYYSFYGLVwP0p+HiN HyR+ZyzkXGGjwallqsOeF0cn7Trie1nLkm1+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gcwmK4UGhFn6j61AETe+5sspMb6jQWmLXiJ2PjAbcCZUK+Wsn2/EI40lLyE2LkyUSE Chds3TLRYtp5AzlVlfTMI9iZKMFlW94o0S3z/qQurUEssPEUFCwk4ujoGR7qM0+JRx+i Y34LTZTO9GdXrX1uZuMGkjCPwhzeKJB3YEW7Q= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 12:46:42 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 12:46:42 -0700 Received: by 10.229.111.81 with SMTP id r17mr10197786qcp.32.1270496824216; Mon, 05 Apr 2010 12:47:04 -0700 (PDT) Message-ID: To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:47:07 -0000 yes. you can have those with a single opaque identifier. the problem is that the large exemplar of the legacy use case does not support those identifiers at the moment, and it's unknown when it will in the future. you COULD simply say that the identifier is: first_name "dot" last_name but then what do you do with names with dots in them? change them in the system? use a blank? what about the names with blanks in them. i think it's an INSANELY GREAT idea to define an entity identifier for agents and account holders, but at the moment and in the near term, there is a requirement that we carry information in a way in which the first name and last name are separate items in the transfer syntax. again. there is NO REQUIREMENT that new systems support the first_name / last_name semantics, but there is a requirement that it be representable in the protocol to support legacy systems. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes wrote: > Maybe I'm missing something here, but if you just had an opaque "client > identifier" field where you could put an arbitrary name chosen by the > provider, surely, then couldn't you just shove something like "Firstname > Lastname" into that field? > > Also, wasn't there also some discussion in the meeting of separating disp= lay > names from identifiers (as is common in IM and email systems)? =A0That wa= y you > could have "Infinity Linden ". > > The only reason you would need to have a (Firstname, Lastname) pair in th= e > *protocol* is if you expected a need for names to be used in that way > interoperably. =A0For example, my avatar walks into a new region operated= by a > party I've never met before, and the new region greets me by first name. = =A0Is > that what you're thinking? > > (Even then, you could address with parsing, if this were not regarded as = a > critical use case. =A0See Gmail's "first name extraction" in Inbox messag= e > summaries.) > > --Richard > > > On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > >> i thought it did for a little bit >> >> basically here's the rub. >> >> sure, we can remove this bit of SL legacy from the protocol, but >> linden is unlikely to drop support for it from SL. so if it's removed >> from the protocol, then the first name / last name option for >> authentication (which is currently used by both SL and OpenSim) will >> need to be described in a proprietary extension to the auth spec. >> >> is this really what we want? >> >> do we really want to make it HARDER to access existing services run by >> organizations and individuals who are interested in making VWRAP a >> success? >> >> i still don't understand why keeping first name / last name as an >> OPTION is a problem for people. as far as i can tell, the people who >> prefer this course of action are morgaine and carlo, neither of which >> has indicated they will be implementing this specification. >> >> calling for the removal of other people's use cases is a bit rude. >> while this is not an effort to "bless" linden's Second Life model and >> legacy protocol, it is also not an effort to bury it. >> >> the current draft allows for EITHER an account identifier or an agent >> identifier to be used to identify a user for the purpose of >> authentication. if you want to use a single opaque identifier, use the >> account identifier. if you want to use a first name / last name, use >> the agent identifier. there is no requirement that an authentication >> service support both. the requirement is, that if you support the >> agent identifier, you use the map defined in the draft. >> >> as it stands now, the account identifier was intended to be used in >> conjunction with agent identifiers in case a user had multiple avatars >> attached to a single "account." maybe we could change it to this: >> >> =A0; agent identifier >> >> =A0&agent_identifier =3D { >> =A0 name: [ string, ... ] >> =A0} >> >> =A0; account identifier >> >> =A0&account_identifier =3D { >> =A0 type : 'account', >> =A0 agents: [ &agent_identifier, ... ], >> =A0} >> >> in this proposal, the data used to identify the user is an array. for >> systems like second life and OpenSim that want to use two names to >> identify users' agents can. systems that want to use a single account >> name (like an email address) can. >> >> the account identifier goes back to what it was supposed to be: a way >> for a user with multiple avatars to login with an account credential, >> giving a list of agent identifiers the authentication service should >> explicitly check for maintenance. >> >> so, to recap: >> >> a. please don't dis my use case. >> b. account identifiers actually serve a purpose other than just >> identifying an account, they communicate the client's interest int he >> maintenance state of the agents associated with the account. >> c. sure, i'm hip to dropping the last name / first name thing, but >> only if we can do something that supports our use case. (like doing a >> name array) >> d. servers shouldn't be REQUIRED to implement two string identifiers, >> but that being said, there are services that use them and it's >> probably a very good idea for clients to support this use case. >> >> -cheers >> -meadhbh >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> wrote: >>> >>> At the IETF77 meeting there was talk about removing the first name / la= st >>> name assumptions from the avatar identifier, but it looks like that >>> conversation didn't carry over to the mailing list. Does anyone know ex= actly >>> which I-Ds (and which sections) reference avatar identifiers as >>> first_name+last_name? >>> >>> John >>> _______________________________________________ >>> 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 > > From john.hurliman@intel.com Mon Apr 5 12:55:00 2010 Return-Path: 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 4B9DF3A69BF for ; Mon, 5 Apr 2010 12:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BPR+vrhrAbTd for ; Mon, 5 Apr 2010 12:54:59 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id E2EB53A69B0 for ; Mon, 5 Apr 2010 12:54:58 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 05 Apr 2010 12:53:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,366,1267430400"; d="scan'208";a="262251000" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 05 Apr 2010 12:53:56 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Mon, 5 Apr 2010 13:53:56 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Mon, 5 Apr 2010 13:53:51 -0600 Thread-Topic: [vwrap] Removing first name / last name assumptions? Thread-Index: AcrU95b8XYScK64qQimtJqVbgTpgAgAAHNUA Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:55:00 -0000 Agreed. My current agent domain and region domain implementations treat nam= es as opaque strings, and when it comes time to transition from the VWRAP i= nterop protocol to the LLUDP client/server protocol I parse "First Last" in= to "First" and "Last". Are we seriously considering taking this discussion = off the table because it would be too difficult for Linden Lab to change th= eir AD/RD code to parse { "display_name": "First Last" }? Last time I check= ed, Linden Lab has not contributed any AD/RD code. IBM and the Open Metaver= se Foundation are the ones writing all of the code for this, so if we want = to talk about the hardships of organizations interested in making this a su= ccess let's ask them. John > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, April 05, 2010 12:39 PM > To: Meadhbh Hamrick > Cc: Hurliman, John; vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? >=20 > Maybe I'm missing something here, but if you just had an opaque > "client identifier" field where you could put an arbitrary name chosen > by the provider, surely, then couldn't you just shove something like > "Firstname Lastname" into that field? >=20 > Also, wasn't there also some discussion in the meeting of separating > display names from identifiers (as is common in IM and email > systems)? That way you could have "Infinity Linden > >". >=20 > The only reason you would need to have a (Firstname, Lastname) pair in > the *protocol* is if you expected a need for names to be used in that > way interoperably. For example, my avatar walks into a new region > operated by a party I've never met before, and the new region greets > me by first name. Is that what you're thinking? >=20 > (Even then, you could address with parsing, if this were not regarded > as a critical use case. See Gmail's "first name extraction" in Inbox > message summaries.) >=20 > --Richard >=20 >=20 > On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >=20 > > i thought it did for a little bit > > > > basically here's the rub. > > > > sure, we can remove this bit of SL legacy from the protocol, but > > linden is unlikely to drop support for it from SL. so if it's removed > > from the protocol, then the first name / last name option for > > authentication (which is currently used by both SL and OpenSim) will > > need to be described in a proprietary extension to the auth spec. > > > > is this really what we want? > > > > do we really want to make it HARDER to access existing services run > by > > organizations and individuals who are interested in making VWRAP a > > success? > > > > i still don't understand why keeping first name / last name as an > > OPTION is a problem for people. as far as i can tell, the people who > > prefer this course of action are morgaine and carlo, neither of which > > has indicated they will be implementing this specification. > > > > calling for the removal of other people's use cases is a bit rude. > > while this is not an effort to "bless" linden's Second Life model and > > legacy protocol, it is also not an effort to bury it. > > > > the current draft allows for EITHER an account identifier or an agent > > identifier to be used to identify a user for the purpose of > > authentication. if you want to use a single opaque identifier, use > the > > account identifier. if you want to use a first name / last name, use > > the agent identifier. there is no requirement that an authentication > > service support both. the requirement is, that if you support the > > agent identifier, you use the map defined in the draft. > > > > as it stands now, the account identifier was intended to be used in > > conjunction with agent identifiers in case a user had multiple > avatars > > attached to a single "account." maybe we could change it to this: > > > > ; agent identifier > > > > &agent_identifier =3D { > > name: [ string, ... ] > > } > > > > ; account identifier > > > > &account_identifier =3D { > > type : 'account', > > agents: [ &agent_identifier, ... ], > > } > > > > in this proposal, the data used to identify the user is an array. for > > systems like second life and OpenSim that want to use two names to > > identify users' agents can. systems that want to use a single account > > name (like an email address) can. > > > > the account identifier goes back to what it was supposed to be: a way > > for a user with multiple avatars to login with an account credential, > > giving a list of agent identifiers the authentication service should > > explicitly check for maintenance. > > > > so, to recap: > > > > a. please don't dis my use case. > > b. account identifiers actually serve a purpose other than just > > identifying an account, they communicate the client's interest int he > > maintenance state of the agents associated with the account. > > c. sure, i'm hip to dropping the last name / first name thing, but > > only if we can do something that supports our use case. (like doing a > > name array) > > d. servers shouldn't be REQUIRED to implement two string identifiers, > > but that being said, there are services that use them and it's > > probably a very good idea for clients to support this use case. > > > > -cheers > > -meadhbh > > > > -- > > meadhbh hamrick * it's pronounced "maeve" > > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > > > > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > > > wrote: > >> At the IETF77 meeting there was talk about removing the first > >> name / last name assumptions from the avatar identifier, but it > >> looks like that conversation didn't carry over to the mailing list. > >> Does anyone know exactly which I-Ds (and which sections) reference > >> avatar identifiers as first_name+last_name? > >> > >> John > >> _______________________________________________ > >> 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 From rbarnes@bbn.com Mon Apr 5 12:59:46 2010 Return-Path: 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 366093A69DA for ; Mon, 5 Apr 2010 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 d0QSbAZbXCgm for ; Mon, 5 Apr 2010 12:59:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 01AB23A69B0 for ; Mon, 5 Apr 2010 12:59:44 -0700 (PDT) Received: from [192.1.255.171] (port=54739 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NysST-000D5m-Me; Mon, 05 Apr 2010 15:59:41 -0400 Message-Id: <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> From: Richard Barnes To: Meadhbh Hamrick In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 15:59:40 -0400 References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.936) Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:59:46 -0000 I'm still trying to understand the use case you're trying to support. Here's another guess: 1. I have an agent/account with vwrap.example.com, which has assigned me the identifier "foobar123@vwrap.example.com" and allows me to set whatever display name I want; I pick "f00b@r" (no "firstname lastname") 2. I want to take the agent with this identifier into SL, i.e., authenticate to SL using that identifer. 3. SL requires all agents to be identified / authenticated with "Firstname Lastname" Am I understanding the problem correctly? If so, it seems like you could treat the "Firstname Lastname" as a mapped identifier, with the VWRAP interface to SL (since that will have to be new code anyway) providing the translation. 1. When an unknown ID shows up, ask them to pick a new SL name (in UI) 2. VWRAP layer stores binding between VWRAP ID and SL name for repeat logins 3. VWRAP layer authenticates client to SL as SL name --Richard On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: > yes. you can have those with a single opaque identifier. the problem > is that the large exemplar of the legacy use case does not support > those identifiers at the moment, and it's unknown when it will in the > future. > > you COULD simply say that the identifier is: > > first_name "dot" last_name > > but then what do you do with names with dots in them? change them in > the system? use a blank? what about the names with blanks in them. > > i think it's an INSANELY GREAT idea to define an entity identifier for > agents and account holders, but at the moment and in the near term, > there is a requirement that we carry information in a way in which the > first name and last name are separate items in the transfer syntax. > > again. there is NO REQUIREMENT that new systems support the first_name > / last_name semantics, but there is a requirement that it be > representable in the protocol to support legacy systems. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes > wrote: >> Maybe I'm missing something here, but if you just had an opaque >> "client >> identifier" field where you could put an arbitrary name chosen by the >> provider, surely, then couldn't you just shove something like >> "Firstname >> Lastname" into that field? >> >> Also, wasn't there also some discussion in the meeting of >> separating display >> names from identifiers (as is common in IM and email systems)? >> That way you >> could have "Infinity Linden ". >> >> The only reason you would need to have a (Firstname, Lastname) pair >> in the >> *protocol* is if you expected a need for names to be used in that way >> interoperably. For example, my avatar walks into a new region >> operated by a >> party I've never met before, and the new region greets me by first >> name. Is >> that what you're thinking? >> >> (Even then, you could address with parsing, if this were not >> regarded as a >> critical use case. See Gmail's "first name extraction" in Inbox >> message >> summaries.) >> >> --Richard >> >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >> >>> i thought it did for a little bit >>> >>> basically here's the rub. >>> >>> sure, we can remove this bit of SL legacy from the protocol, but >>> linden is unlikely to drop support for it from SL. so if it's >>> removed >>> from the protocol, then the first name / last name option for >>> authentication (which is currently used by both SL and OpenSim) will >>> need to be described in a proprietary extension to the auth spec. >>> >>> is this really what we want? >>> >>> do we really want to make it HARDER to access existing services >>> run by >>> organizations and individuals who are interested in making VWRAP a >>> success? >>> >>> i still don't understand why keeping first name / last name as an >>> OPTION is a problem for people. as far as i can tell, the people who >>> prefer this course of action are morgaine and carlo, neither of >>> which >>> has indicated they will be implementing this specification. >>> >>> calling for the removal of other people's use cases is a bit rude. >>> while this is not an effort to "bless" linden's Second Life model >>> and >>> legacy protocol, it is also not an effort to bury it. >>> >>> the current draft allows for EITHER an account identifier or an >>> agent >>> identifier to be used to identify a user for the purpose of >>> authentication. if you want to use a single opaque identifier, use >>> the >>> account identifier. if you want to use a first name / last name, use >>> the agent identifier. there is no requirement that an authentication >>> service support both. the requirement is, that if you support the >>> agent identifier, you use the map defined in the draft. >>> >>> as it stands now, the account identifier was intended to be used in >>> conjunction with agent identifiers in case a user had multiple >>> avatars >>> attached to a single "account." maybe we could change it to this: >>> >>> ; agent identifier >>> >>> &agent_identifier = { >>> name: [ string, ... ] >>> } >>> >>> ; account identifier >>> >>> &account_identifier = { >>> type : 'account', >>> agents: [ &agent_identifier, ... ], >>> } >>> >>> in this proposal, the data used to identify the user is an array. >>> for >>> systems like second life and OpenSim that want to use two names to >>> identify users' agents can. systems that want to use a single >>> account >>> name (like an email address) can. >>> >>> the account identifier goes back to what it was supposed to be: a >>> way >>> for a user with multiple avatars to login with an account >>> credential, >>> giving a list of agent identifiers the authentication service should >>> explicitly check for maintenance. >>> >>> so, to recap: >>> >>> a. please don't dis my use case. >>> b. account identifiers actually serve a purpose other than just >>> identifying an account, they communicate the client's interest int >>> he >>> maintenance state of the agents associated with the account. >>> c. sure, i'm hip to dropping the last name / first name thing, but >>> only if we can do something that supports our use case. (like >>> doing a >>> name array) >>> d. servers shouldn't be REQUIRED to implement two string >>> identifiers, >>> but that being said, there are services that use them and it's >>> probably a very good idea for clients to support this use case. >>> >>> -cheers >>> -meadhbh >>> >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> > >>> wrote: >>>> >>>> At the IETF77 meeting there was talk about removing the first >>>> name / last >>>> name assumptions from the avatar identifier, but it looks like that >>>> conversation didn't carry over to the mailing list. Does anyone >>>> know exactly >>>> which I-Ds (and which sections) reference avatar identifiers as >>>> first_name+last_name? >>>> >>>> John >>>> _______________________________________________ >>>> 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 >> >> From ohmeadhbh@gmail.com Mon Apr 5 13:07:45 2010 Return-Path: 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 CA8B13A6A75 for ; Mon, 5 Apr 2010 13:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 mOSXFRT0Q6MW for ; Mon, 5 Apr 2010 13:07:44 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id C98723A6A7A for ; Mon, 5 Apr 2010 13:07:43 -0700 (PDT) Received: by qyk11 with SMTP id 11so4317351qyk.13 for ; Mon, 05 Apr 2010 13:07:37 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xFwVdTPC0CYuBrdeq4LstpMjBAcqkiJKQD2HYZC4lXc=; b=bZOPohSGqNKOqV+6pOmYiJzRu/xLJo9zEdvL41iiC+FcbFraOv92MT6Fge/aErGBte /QyRbrhFjHML6JgUP0qTvmHlq9MERkFh4kyEPHsnhWQaeTlGxAg1UFrj3wy+uGJd/xbg GPhKisGJpwu9rxNsrdBfyjBoVuSU63+eul2Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rz5rsOpWTO1niGWVsdJWJeNJHcmKAJ1zVHnrtU2Wdz1KIQIJlOllcg2wr6nnv+jTSA EwU1aIa43qOAmpFklOMaTWOOMvD39LQlCpI7/seorDLcHx3vREqpCKEku5ji/cWsTwDN e1KoDcq7YRd3R9XdghM0B6ULjUnFDZNc0BRTI= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 13:07:15 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 13:07:15 -0700 Received: by 10.229.217.1 with SMTP id hk1mr1720248qcb.81.1270498055340; Mon, 05 Apr 2010 13:07:35 -0700 (PDT) Message-ID: To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:07:45 -0000 no. we're proposing taking it off the table because there is a very high likelihood that are valid first and/or last names in a particular implementation that include spaces and periods. this is the reason we came up with having first_name and last_name as separate strings in the transfer syntax, and not a single string identifying the avatar's name. why do we need to REMOVE support for Second Life from this protocol? also... why do we need to define a display name when logging into the agent domain? shouldn't we specify one when we're rezzing an agent in a region? i'm hip to adding it if there's a need, but please don't remove support for things required for other people's implementations. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John w= rote: > Agreed. My current agent domain and region domain implementations treat n= ames as opaque strings, and when it comes time to transition from the VWRAP= interop protocol to the LLUDP client/server protocol I parse "First Last" = into "First" and "Last". Are we seriously considering taking this discussio= n off the table because it would be too difficult for Linden Lab to change = their AD/RD code to parse { "display_name": "First Last" }? Last time I che= cked, Linden Lab has not contributed any AD/RD code. IBM and the Open Metav= erse Foundation are the ones writing all of the code for this, so if we wan= t to talk about the hardships of organizations interested in making this a = success let's ask them. > > John > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Monday, April 05, 2010 12:39 PM >> To: Meadhbh Hamrick >> Cc: Hurliman, John; vwrap@ietf.org >> Subject: Re: [vwrap] Removing first name / last name assumptions? >> >> Maybe I'm missing something here, but if you just had an opaque >> "client identifier" field where you could put an arbitrary name chosen >> by the provider, surely, then couldn't you just shove something like >> "Firstname Lastname" into that field? >> >> Also, wasn't there also some discussion in the meeting of separating >> display names from identifiers (as is common in IM and email >> systems)? =A0That way you could have "Infinity Linden >> > =A0>". >> >> The only reason you would need to have a (Firstname, Lastname) pair in >> the *protocol* is if you expected a need for names to be used in that >> way interoperably. =A0For example, my avatar walks into a new region >> operated by a party I've never met before, and the new region greets >> me by first name. =A0Is that what you're thinking? >> >> (Even then, you could address with parsing, if this were not regarded >> as a critical use case. =A0See Gmail's "first name extraction" in Inbox >> message summaries.) >> >> --Richard >> >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >> >> > i thought it did for a little bit >> > >> > basically here's the rub. >> > >> > sure, we can remove this bit of SL legacy from the protocol, but >> > linden is unlikely to drop support for it from SL. so if it's removed >> > from the protocol, then the first name / last name option for >> > authentication (which is currently used by both SL and OpenSim) will >> > need to be described in a proprietary extension to the auth spec. >> > >> > is this really what we want? >> > >> > do we really want to make it HARDER to access existing services run >> by >> > organizations and individuals who are interested in making VWRAP a >> > success? >> > >> > i still don't understand why keeping first name / last name as an >> > OPTION is a problem for people. as far as i can tell, the people who >> > prefer this course of action are morgaine and carlo, neither of which >> > has indicated they will be implementing this specification. >> > >> > calling for the removal of other people's use cases is a bit rude. >> > while this is not an effort to "bless" linden's Second Life model and >> > legacy protocol, it is also not an effort to bury it. >> > >> > the current draft allows for EITHER an account identifier or an agent >> > identifier to be used to identify a user for the purpose of >> > authentication. if you want to use a single opaque identifier, use >> the >> > account identifier. if you want to use a first name / last name, use >> > the agent identifier. there is no requirement that an authentication >> > service support both. the requirement is, that if you support the >> > agent identifier, you use the map defined in the draft. >> > >> > as it stands now, the account identifier was intended to be used in >> > conjunction with agent identifiers in case a user had multiple >> avatars >> > attached to a single "account." maybe we could change it to this: >> > >> > =A0; agent identifier >> > >> > =A0&agent_identifier =3D { >> > =A0 =A0name: [ string, ... ] >> > =A0} >> > >> > =A0; account identifier >> > >> > =A0&account_identifier =3D { >> > =A0 =A0type : 'account', >> > =A0 =A0agents: [ &agent_identifier, ... ], >> > =A0} >> > >> > in this proposal, the data used to identify the user is an array. for >> > systems like second life and OpenSim that want to use two names to >> > identify users' agents can. systems that want to use a single account >> > name (like an email address) can. >> > >> > the account identifier goes back to what it was supposed to be: a way >> > for a user with multiple avatars to login with an account credential, >> > giving a list of agent identifiers the authentication service should >> > explicitly check for maintenance. >> > >> > so, to recap: >> > >> > a. please don't dis my use case. >> > b. account identifiers actually serve a purpose other than just >> > identifying an account, they communicate the client's interest int he >> > maintenance state of the agents associated with the account. >> > c. sure, i'm hip to dropping the last name / first name thing, but >> > only if we can do something that supports our use case. (like doing a >> > name array) >> > d. servers shouldn't be REQUIRED to implement two string identifiers, >> > but that being said, there are services that use them and it's >> > probably a very good idea for clients to support this use case. >> > >> > -cheers >> > -meadhbh >> > >> > -- >> > meadhbh hamrick * it's pronounced "maeve" >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> > >> > >> > >> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> > > > wrote: >> >> At the IETF77 meeting there was talk about removing the first >> >> name / last name assumptions from the avatar identifier, but it >> >> looks like that conversation didn't carry over to the mailing list. >> >> Does anyone know exactly which I-Ds (and which sections) reference >> >> avatar identifiers as first_name+last_name? >> >> >> >> John >> >> _______________________________________________ >> >> 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 > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From djshag@hotmail.com Mon Apr 5 13:27:18 2010 Return-Path: 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 B9DE828C18F for ; Mon, 5 Apr 2010 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=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 VWltCDBM8y+m for ; Mon, 5 Apr 2010 13:27:17 -0700 (PDT) Received: from bay0-omc2-s25.bay0.hotmail.com (bay0-omc2-s25.bay0.hotmail.com [65.54.190.100]) by core3.amsl.com (Postfix) with ESMTP id 2CEF928C19A for ; Mon, 5 Apr 2010 13:17:52 -0700 (PDT) Received: from BAY136-DS16 ([65.54.190.125]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 13:17:50 -0700 X-Originating-IP: [74.57.140.246] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: "Meadhbh Hamrick" References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> In-Reply-To: Date: Mon, 5 Apr 2010 16:17:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-OriginalArrivalTime: 05 Apr 2010 20:17:50.0630 (UTC) FILETIME=[10BFCC60:01CAD4FD] Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:27:18 -0000 Some of the people in this list seem to believe that LL code is god re-incarnate. Those kind of comments seem to have hold you back for a great deal of time already. Those guys, John and others, don't want to remove "support" of second life in the protocol. They want to create a generic protocol that LL can (if they really wish..) use to connect to other worlds. So some adaptation will be needed from LL side also. Like first name / last name implementation, it can make sense for LL but for all the rest of the internet it doesn't, look at facebook for example (one great competitor isn't it...) they're not using firstname / lastname for login but some guys at LL think its the best way to do it.. well.. those guys might find out their way isn't the best after all (maybe they will only find out when a whole new metaverse will be created using VWRAP and LL is falling behind.. who knows). Just my 2 cents, good work guys at Intel and IBM i'll always support your effort! -------------------------------------------------- From: "Meadhbh Hamrick" Sent: Monday, April 05, 2010 4:07 PM To: "Hurliman, John" Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? > no. we're proposing taking it off the table because there is a very > high likelihood that are valid first and/or last names in a particular > implementation that include spaces and periods. this is the reason we > came up with having first_name and last_name as separate strings in > the transfer syntax, and not a single string identifying the avatar's > name. > > why do we need to REMOVE support for Second Life from this protocol? > > also... why do we need to define a display name when logging into the > agent domain? shouldn't we specify one when we're rezzing an agent in > a region? > > i'm hip to adding it if there's a need, but please don't remove > support for things required for other people's implementations. > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John > wrote: >> Agreed. My current agent domain and region domain implementations treat >> names as opaque strings, and when it comes time to transition from the >> VWRAP interop protocol to the LLUDP client/server protocol I parse "First >> Last" into "First" and "Last". Are we seriously considering taking this >> discussion off the table because it would be too difficult for Linden Lab >> to change their AD/RD code to parse { "display_name": "First Last" }? >> Last time I checked, Linden Lab has not contributed any AD/RD code. IBM >> and the Open Metaverse Foundation are the ones writing all of the code >> for this, so if we want to talk about the hardships of organizations >> interested in making this a success let's ask them. >> >> John >> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Monday, April 05, 2010 12:39 PM >>> To: Meadhbh Hamrick >>> Cc: Hurliman, John; vwrap@ietf.org >>> Subject: Re: [vwrap] Removing first name / last name assumptions? >>> >>> Maybe I'm missing something here, but if you just had an opaque >>> "client identifier" field where you could put an arbitrary name chosen >>> by the provider, surely, then couldn't you just shove something like >>> "Firstname Lastname" into that field? >>> >>> Also, wasn't there also some discussion in the meeting of separating >>> display names from identifiers (as is common in IM and email >>> systems)? That way you could have "Infinity Linden >>> >> >". >>> >>> The only reason you would need to have a (Firstname, Lastname) pair in >>> the *protocol* is if you expected a need for names to be used in that >>> way interoperably. For example, my avatar walks into a new region >>> operated by a party I've never met before, and the new region greets >>> me by first name. Is that what you're thinking? >>> >>> (Even then, you could address with parsing, if this were not regarded >>> as a critical use case. See Gmail's "first name extraction" in Inbox >>> message summaries.) >>> >>> --Richard >>> >>> >>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >>> >>> > i thought it did for a little bit >>> > >>> > basically here's the rub. >>> > >>> > sure, we can remove this bit of SL legacy from the protocol, but >>> > linden is unlikely to drop support for it from SL. so if it's removed >>> > from the protocol, then the first name / last name option for >>> > authentication (which is currently used by both SL and OpenSim) will >>> > need to be described in a proprietary extension to the auth spec. >>> > >>> > is this really what we want? >>> > >>> > do we really want to make it HARDER to access existing services run >>> by >>> > organizations and individuals who are interested in making VWRAP a >>> > success? >>> > >>> > i still don't understand why keeping first name / last name as an >>> > OPTION is a problem for people. as far as i can tell, the people who >>> > prefer this course of action are morgaine and carlo, neither of which >>> > has indicated they will be implementing this specification. >>> > >>> > calling for the removal of other people's use cases is a bit rude. >>> > while this is not an effort to "bless" linden's Second Life model and >>> > legacy protocol, it is also not an effort to bury it. >>> > >>> > the current draft allows for EITHER an account identifier or an agent >>> > identifier to be used to identify a user for the purpose of >>> > authentication. if you want to use a single opaque identifier, use >>> the >>> > account identifier. if you want to use a first name / last name, use >>> > the agent identifier. there is no requirement that an authentication >>> > service support both. the requirement is, that if you support the >>> > agent identifier, you use the map defined in the draft. >>> > >>> > as it stands now, the account identifier was intended to be used in >>> > conjunction with agent identifiers in case a user had multiple >>> avatars >>> > attached to a single "account." maybe we could change it to this: >>> > >>> > ; agent identifier >>> > >>> > &agent_identifier = { >>> > name: [ string, ... ] >>> > } >>> > >>> > ; account identifier >>> > >>> > &account_identifier = { >>> > type : 'account', >>> > agents: [ &agent_identifier, ... ], >>> > } >>> > >>> > in this proposal, the data used to identify the user is an array. for >>> > systems like second life and OpenSim that want to use two names to >>> > identify users' agents can. systems that want to use a single account >>> > name (like an email address) can. >>> > >>> > the account identifier goes back to what it was supposed to be: a way >>> > for a user with multiple avatars to login with an account credential, >>> > giving a list of agent identifiers the authentication service should >>> > explicitly check for maintenance. >>> > >>> > so, to recap: >>> > >>> > a. please don't dis my use case. >>> > b. account identifiers actually serve a purpose other than just >>> > identifying an account, they communicate the client's interest int he >>> > maintenance state of the agents associated with the account. >>> > c. sure, i'm hip to dropping the last name / first name thing, but >>> > only if we can do something that supports our use case. (like doing a >>> > name array) >>> > d. servers shouldn't be REQUIRED to implement two string identifiers, >>> > but that being said, there are services that use them and it's >>> > probably a very good idea for clients to support this use case. >>> > >>> > -cheers >>> > -meadhbh >>> > >>> > -- >>> > meadhbh hamrick * it's pronounced "maeve" >>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> > >>> > >>> > >>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >>> >> > > wrote: >>> >> At the IETF77 meeting there was talk about removing the first >>> >> name / last name assumptions from the avatar identifier, but it >>> >> looks like that conversation didn't carry over to the mailing list. >>> >> Does anyone know exactly which I-Ds (and which sections) reference >>> >> avatar identifiers as first_name+last_name? >>> >> >>> >> John >>> >> _______________________________________________ >>> >> 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 >> >> _______________________________________________ >> 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 > From ohmeadhbh@gmail.com Mon Apr 5 13:29:55 2010 Return-Path: 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 421F83A69E5 for ; Mon, 5 Apr 2010 13:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 I5Td+FPfotSX for ; Mon, 5 Apr 2010 13:29:53 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 5921C3A6A85 for ; Mon, 5 Apr 2010 13:25:45 -0700 (PDT) Received: by qyk11 with SMTP id 11so4333495qyk.13 for ; Mon, 05 Apr 2010 13:25:39 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WhZaalJyOsW01cp/FNTTCr1rp0YELtM9ICIAwT0gHAg=; b=YbBI8ZGK6tbicwGU1NKwolsSLbKo7rmzfUOwrQcn488UBHatfGzxB2rMmDRy9wlJgd YZWaAMnbR/P+k/TwGqFY44C3nCtUq70AZWJb6uzbGl67O4uCl7Q+Dvos2Y7ci7ZEP7ZP sAFCl6uqc14fJteE4stshFbno0xG2Cen2EQ48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=r3E+CjXnxskakcv12kK5GksTLA2QmFp39Q8nG0SZFgx7sziF7uh5PrSshOYdi9OvAf 7JVdlLRq+VHgH26ATrliL5bzcLmFxWyPGvXfHzNrg+urKAOqeDnKB9QyV0SXvWqZNuDj tm1O9j1KQodamHjKQKJcDao9eY2zIskyrp2Zk= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 13:25:19 -0700 (PDT) In-Reply-To: <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 13:25:19 -0700 Received: by 10.229.242.3 with SMTP id lg3mr2226657qcb.102.1270499139115; Mon, 05 Apr 2010 13:25:39 -0700 (PDT) Message-ID: To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:29:55 -0000 VWRAP is a protocol intended to support some legacy implementations like OpenSim and Second Life. in at least one of these implementations there are first and or last names that somehow managed to get spaces and periods (and if i remember correctly, some commas got in there too.) if we wanted to construct an entity identifier by concatenating the first name, a separator and a last name, we would have to find a separator that was not currently in use. imagine the case of having the first name "le roy" and the last name of "barr", if we used a blank as a separator, our identifier would be "le roy barr". when it came time to parse this, there would be an ambiguity as to whether the first name was "le" and the last name "roy barr" or the first name "le roy" and the last name "barr". so rather than cancel these accounts or rename them, we created an optional identifier in the protocol that used two distinct strings to identify the first and last names. in the future, Second Life COULD use single string identifiers like the examples you give below, but it currently only supports first / last authentication. it is likely that before SL uses single string IDs to identify users, they will simply add a VWRAP interface to the existing implementation. an implementation that needs both a first name and a last name. while i agree with you that it would be preferential to have a single string identifier (which is why we're having this discussion), REQUIRING it's use would REQUIRE Linden to invest a fair amount of effort before any return on supporting the standard would be realized. by defining two identifiers (or using an array for identifiers and LL telling everyone "we map that as first name and last name") and giving deployers the choice of which to use, we can have a protocol that will be deployed more quickly by a large virtual world. deploying faster means we'll get experience faster and will be able to potentially modify the standard to prevent us from specifying ourselves into a corner. please remember, there is absolutely NOTHING in the spec that REQUIRES an authentication service in an agent domain to support the "two string identifier" use case. the requirement is... if you use two distinct strings to identify an agent, you must do it in a way that adheres to whatever specification we come up with here for two string identifiers. may i ask which implementation has the requirement that identifiers used in authentication NOT use two distinct strings? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 12:59 PM, Richard Barnes wrote: > I'm still trying to understand the use case you're trying to support. > =A0Here's another guess: > > 1. I have an agent/account with vwrap.example.com, which has assigned me = the > identifier "foobar123@vwrap.example.com" and allows me to set whatever > display name I want; I pick "f00b@r" (no "firstname lastname") > > 2. I want to take the agent with this identifier into SL, i.e., authentic= ate > to SL using that identifer. > > 3. SL requires all agents to be identified / authenticated with "Firstnam= e > Lastname" > > Am I understanding the problem correctly? > > If so, it seems like you could treat the "Firstname Lastname" as a mapped > identifier, with the VWRAP interface to SL (since that will have to be ne= w > code anyway) providing the translation. > 1. When an unknown ID shows up, ask them to pick a new SL name (in UI) > 2. VWRAP layer stores binding between VWRAP ID and SL name for repeat log= ins > 3. VWRAP layer authenticates client to SL as SL name > > --Richard > > > > On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: > >> yes. you can have those with a single opaque identifier. the problem >> is that the large exemplar of the legacy use case does not support >> those identifiers at the moment, and it's unknown when it will in the >> future. >> >> you COULD simply say that the identifier is: >> >> first_name "dot" last_name >> >> but then what do you do with names with dots in them? change them in >> the system? use a blank? what about the names with blanks in them. >> >> i think it's an INSANELY GREAT idea to define an entity identifier for >> agents and account holders, but at the moment and in the near term, >> there is a requirement that we carry information in a way in which the >> first name and last name are separate items in the transfer syntax. >> >> again. there is NO REQUIREMENT that new systems support the first_name >> / last_name semantics, but there is a requirement that it be >> representable in the protocol to support legacy systems. >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes wrote: >>> >>> Maybe I'm missing something here, but if you just had an opaque "client >>> identifier" field where you could put an arbitrary name chosen by the >>> provider, surely, then couldn't you just shove something like "Firstnam= e >>> Lastname" into that field? >>> >>> Also, wasn't there also some discussion in the meeting of separating >>> display >>> names from identifiers (as is common in IM and email systems)? =A0That = way >>> you >>> could have "Infinity Linden ". >>> >>> The only reason you would need to have a (Firstname, Lastname) pair in >>> the >>> *protocol* is if you expected a need for names to be used in that way >>> interoperably. =A0For example, my avatar walks into a new region operat= ed >>> by a >>> party I've never met before, and the new region greets me by first name= . >>> =A0Is >>> that what you're thinking? >>> >>> (Even then, you could address with parsing, if this were not regarded a= s >>> a >>> critical use case. =A0See Gmail's "first name extraction" in Inbox mess= age >>> summaries.) >>> >>> --Richard >>> >>> >>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >>> >>>> i thought it did for a little bit >>>> >>>> basically here's the rub. >>>> >>>> sure, we can remove this bit of SL legacy from the protocol, but >>>> linden is unlikely to drop support for it from SL. so if it's removed >>>> from the protocol, then the first name / last name option for >>>> authentication (which is currently used by both SL and OpenSim) will >>>> need to be described in a proprietary extension to the auth spec. >>>> >>>> is this really what we want? >>>> >>>> do we really want to make it HARDER to access existing services run by >>>> organizations and individuals who are interested in making VWRAP a >>>> success? >>>> >>>> i still don't understand why keeping first name / last name as an >>>> OPTION is a problem for people. as far as i can tell, the people who >>>> prefer this course of action are morgaine and carlo, neither of which >>>> has indicated they will be implementing this specification. >>>> >>>> calling for the removal of other people's use cases is a bit rude. >>>> while this is not an effort to "bless" linden's Second Life model and >>>> legacy protocol, it is also not an effort to bury it. >>>> >>>> the current draft allows for EITHER an account identifier or an agent >>>> identifier to be used to identify a user for the purpose of >>>> authentication. if you want to use a single opaque identifier, use the >>>> account identifier. if you want to use a first name / last name, use >>>> the agent identifier. there is no requirement that an authentication >>>> service support both. the requirement is, that if you support the >>>> agent identifier, you use the map defined in the draft. >>>> >>>> as it stands now, the account identifier was intended to be used in >>>> conjunction with agent identifiers in case a user had multiple avatars >>>> attached to a single "account." maybe we could change it to this: >>>> >>>> =A0; agent identifier >>>> >>>> =A0&agent_identifier =3D { >>>> =A0name: [ string, ... ] >>>> =A0} >>>> >>>> =A0; account identifier >>>> >>>> =A0&account_identifier =3D { >>>> =A0type : 'account', >>>> =A0agents: [ &agent_identifier, ... ], >>>> =A0} >>>> >>>> in this proposal, the data used to identify the user is an array. for >>>> systems like second life and OpenSim that want to use two names to >>>> identify users' agents can. systems that want to use a single account >>>> name (like an email address) can. >>>> >>>> the account identifier goes back to what it was supposed to be: a way >>>> for a user with multiple avatars to login with an account credential, >>>> giving a list of agent identifiers the authentication service should >>>> explicitly check for maintenance. >>>> >>>> so, to recap: >>>> >>>> a. please don't dis my use case. >>>> b. account identifiers actually serve a purpose other than just >>>> identifying an account, they communicate the client's interest int he >>>> maintenance state of the agents associated with the account. >>>> c. sure, i'm hip to dropping the last name / first name thing, but >>>> only if we can do something that supports our use case. (like doing a >>>> name array) >>>> d. servers shouldn't be REQUIRED to implement two string identifiers, >>>> but that being said, there are services that use them and it's >>>> probably a very good idea for clients to support this use case. >>>> >>>> -cheers >>>> -meadhbh >>>> >>>> -- >>>> meadhbh hamrick * it's pronounced "maeve" >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>> >>>> >>>> >>>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >>>> >>>> wrote: >>>>> >>>>> At the IETF77 meeting there was talk about removing the first name / >>>>> last >>>>> name assumptions from the avatar identifier, but it looks like that >>>>> conversation didn't carry over to the mailing list. Does anyone know >>>>> exactly >>>>> which I-Ds (and which sections) reference avatar identifiers as >>>>> first_name+last_name? >>>>> >>>>> John >>>>> _______________________________________________ >>>>> 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 >>> >>> > > From ohmeadhbh@gmail.com Mon Apr 5 13:32:34 2010 Return-Path: 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 706F43A6A97 for ; Mon, 5 Apr 2010 13:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] 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 d7TOLzs1DWV8 for ; Mon, 5 Apr 2010 13:32:33 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 405EC28C1D1 for ; Mon, 5 Apr 2010 13:29:36 -0700 (PDT) Received: by qyk11 with SMTP id 11so4336989qyk.13 for ; Mon, 05 Apr 2010 13:29:29 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=dbMI0r9funtC1F7SVL/pYaieQgKeT9t1Mu9NuLgmay0=; b=jCcw6OnZ5Iah2i7qPUmJz73pNx2ccvhl+B+UVPtb80vbLLK3AYy65a3PyH2XJ/QFQd 3WMEjImdMAPlz/cXugXUXG0RcXGax6xT5+fVIALn8kV5heMf8Le7QDc++X/zPL4qAyR7 XI0YBuovIXzmuwiKwhACOkdgRSXab1av8/39M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TSAPXGKTQp8g8Xm6mCC0rVaqBj7kcSjvKesEmdBwOAjFfFrv57BS0Hc2K1WQ3n2Tnq YG4YOKrxdIQrmJVSK3E/89+77uEfEJmAtsRewxunXTkKcAF2bimsOCJZm8Mj73JP9xwl kFXMb6ZwcU4xDHnC7ewI3ds2GTnzB/XDFUnKA= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 13:29:09 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 13:29:09 -0700 Received: by 10.229.91.11 with SMTP id k11mr8414867qcm.50.1270499369196; Mon, 05 Apr 2010 13:29:29 -0700 (PDT) Message-ID: To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:32:34 -0000 the length thing is a good point. if we asked LL about it, i would suspect the answer we would get back would be: "there's no reason for that to be in the protocol, we can simply provide an error if someone gives an invalid name." in other words, what is the use of checking if the first name and last name strings are greater than 32 characters if there's no way for a valid name to have more than 32 chars in each? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John wr= ote: > That sounds like a fine approach, but retrofitting the UI to pick a new a= vatar name into the existing protocol and codebase is tricky. Right now I j= ust do a best attempt at parsing the first/last name. It looks for the firs= t " " character to split on; if that's not found it uses the whole string a= s a first name along with a default last name (Guest, I think). Then it tri= ms the first and last name to the maximum allowable length and removes any = illegal characters. > > If you really want to make this support the SL use case, change the draft= to restrict "first" and "last" to a maximum of 32 characters and only allo= w alphanumeric ASCII characters. > > John > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Monday, April 05, 2010 1:00 PM >> To: Meadhbh Hamrick >> Cc: Hurliman, John; vwrap@ietf.org >> Subject: Re: [vwrap] Removing first name / last name assumptions? >> >> I'm still trying to understand the use case you're trying to support. >> Here's another guess: >> >> 1. I have an agent/account with vwrap.example.com, which has assigned >> me the identifier "foobar123@vwrap.example.com" and allows me to set >> whatever display name I want; I pick "f00b@r" (no "firstname lastname") >> >> 2. I want to take the agent with this identifier into SL, i.e., >> authenticate to SL using that identifer. >> >> 3. SL requires all agents to be identified / authenticated with >> "Firstname Lastname" >> >> Am I understanding the problem correctly? >> >> If so, it seems like you could treat the "Firstname Lastname" as a >> mapped identifier, with the VWRAP interface to SL (since that will >> have to be new code anyway) providing the translation. >> 1. When an unknown ID shows up, ask them to pick a new SL name (in UI) >> 2. VWRAP layer stores binding between VWRAP ID and SL name for repeat >> logins >> 3. VWRAP layer authenticates client to SL as SL name >> >> --Richard >> >> >> >> On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: >> >> > yes. you can have those with a single opaque identifier. the problem >> > is that the large exemplar of the legacy use case does not support >> > those identifiers at the moment, and it's unknown when it will in the >> > future. >> > >> > you COULD simply say that the identifier is: >> > >> > first_name "dot" last_name >> > >> > but then what do you do with names with dots in them? change them in >> > the system? use a blank? what about the names with blanks in them. >> > >> > i think it's an INSANELY GREAT idea to define an entity identifier >> for >> > agents and account holders, but at the moment and in the near term, >> > there is a requirement that we carry information in a way in which >> the >> > first name and last name are separate items in the transfer syntax. >> > >> > again. there is NO REQUIREMENT that new systems support the >> first_name >> > / last_name semantics, but there is a requirement that it be >> > representable in the protocol to support legacy systems. >> > >> > -cheers >> > -meadhbh >> > -- >> > meadhbh hamrick * it's pronounced "maeve" >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> > >> > >> > >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes >> > wrote: >> >> Maybe I'm missing something here, but if you just had an opaque >> >> "client >> >> identifier" field where you could put an arbitrary name chosen by >> the >> >> provider, surely, then couldn't you just shove something like >> >> "Firstname >> >> Lastname" into that field? >> >> >> >> Also, wasn't there also some discussion in the meeting of >> >> separating display >> >> names from identifiers (as is common in IM and email systems)? >> >> That way you >> >> could have "Infinity Linden ". >> >> >> >> The only reason you would need to have a (Firstname, Lastname) pair >> >> in the >> >> *protocol* is if you expected a need for names to be used in that >> way >> >> interoperably. =A0For example, my avatar walks into a new region >> >> operated by a >> >> party I've never met before, and the new region greets me by first >> >> name. =A0Is >> >> that what you're thinking? >> >> >> >> (Even then, you could address with parsing, if this were not >> >> regarded as a >> >> critical use case. =A0See Gmail's "first name extraction" in Inbox >> >> message >> >> summaries.) >> >> >> >> --Richard >> >> >> >> >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >> >> >> >>> i thought it did for a little bit >> >>> >> >>> basically here's the rub. >> >>> >> >>> sure, we can remove this bit of SL legacy from the protocol, but >> >>> linden is unlikely to drop support for it from SL. so if it's >> >>> removed >> >>> from the protocol, then the first name / last name option for >> >>> authentication (which is currently used by both SL and OpenSim) >> will >> >>> need to be described in a proprietary extension to the auth spec. >> >>> >> >>> is this really what we want? >> >>> >> >>> do we really want to make it HARDER to access existing services >> >>> run by >> >>> organizations and individuals who are interested in making VWRAP a >> >>> success? >> >>> >> >>> i still don't understand why keeping first name / last name as an >> >>> OPTION is a problem for people. as far as i can tell, the people >> who >> >>> prefer this course of action are morgaine and carlo, neither of >> >>> which >> >>> has indicated they will be implementing this specification. >> >>> >> >>> calling for the removal of other people's use cases is a bit rude. >> >>> while this is not an effort to "bless" linden's Second Life model >> >>> and >> >>> legacy protocol, it is also not an effort to bury it. >> >>> >> >>> the current draft allows for EITHER an account identifier or an >> >>> agent >> >>> identifier to be used to identify a user for the purpose of >> >>> authentication. if you want to use a single opaque identifier, use >> >>> the >> >>> account identifier. if you want to use a first name / last name, >> use >> >>> the agent identifier. there is no requirement that an >> authentication >> >>> service support both. the requirement is, that if you support the >> >>> agent identifier, you use the map defined in the draft. >> >>> >> >>> as it stands now, the account identifier was intended to be used in >> >>> conjunction with agent identifiers in case a user had multiple >> >>> avatars >> >>> attached to a single "account." maybe we could change it to this: >> >>> >> >>> =A0; agent identifier >> >>> >> >>> =A0&agent_identifier =3D { >> >>> =A0 name: [ string, ... ] >> >>> =A0} >> >>> >> >>> =A0; account identifier >> >>> >> >>> =A0&account_identifier =3D { >> >>> =A0 type : 'account', >> >>> =A0 agents: [ &agent_identifier, ... ], >> >>> =A0} >> >>> >> >>> in this proposal, the data used to identify the user is an array. >> >>> for >> >>> systems like second life and OpenSim that want to use two names to >> >>> identify users' agents can. systems that want to use a single >> >>> account >> >>> name (like an email address) can. >> >>> >> >>> the account identifier goes back to what it was supposed to be: a >> >>> way >> >>> for a user with multiple avatars to login with an account >> >>> credential, >> >>> giving a list of agent identifiers the authentication service >> should >> >>> explicitly check for maintenance. >> >>> >> >>> so, to recap: >> >>> >> >>> a. please don't dis my use case. >> >>> b. account identifiers actually serve a purpose other than just >> >>> identifying an account, they communicate the client's interest int >> >>> he >> >>> maintenance state of the agents associated with the account. >> >>> c. sure, i'm hip to dropping the last name / first name thing, but >> >>> only if we can do something that supports our use case. (like >> >>> doing a >> >>> name array) >> >>> d. servers shouldn't be REQUIRED to implement two string >> >>> identifiers, >> >>> but that being said, there are services that use them and it's >> >>> probably a very good idea for clients to support this use case. >> >>> >> >>> -cheers >> >>> -meadhbh >> >>> >> >>> -- >> >>> meadhbh hamrick * it's pronounced "maeve" >> >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >>> >> >>> >> >>> >> >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> > >>> > >> >>> wrote: >> >>>> >> >>>> At the IETF77 meeting there was talk about removing the first >> >>>> name / last >> >>>> name assumptions from the avatar identifier, but it looks like >> that >> >>>> conversation didn't carry over to the mailing list. Does anyone >> >>>> know exactly >> >>>> which I-Ds (and which sections) reference avatar identifiers as >> >>>> first_name+last_name? >> >>>> >> >>>> John >> >>>> _______________________________________________ >> >>>> 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 >> >> >> >> > > From john.hurliman@intel.com Mon Apr 5 13:39:36 2010 Return-Path: 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 24E823A6A7A for ; Mon, 5 Apr 2010 13:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LQaLBBIbZU5w for ; Mon, 5 Apr 2010 13:39:34 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 89DA63A6A7F for ; Mon, 5 Apr 2010 13:39:34 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 05 Apr 2010 13:11:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,366,1267430400"; d="scan'208";a="555133441" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga002.fm.intel.com with ESMTP; 05 Apr 2010 13:11:56 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Apr 2010 14:12:02 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Mon, 5 Apr 2010 14:12:01 -0600 From: "Hurliman, John" To: Richard Barnes , Meadhbh Hamrick Date: Mon, 5 Apr 2010 14:11:59 -0600 Thread-Topic: [vwrap] Removing first name / last name assumptions? Thread-Index: AcrU+ooLhHsRE9MkTWS3vU1PPvFoTAAAJkHg Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> In-Reply-To: <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:39:36 -0000 That sounds like a fine approach, but retrofitting the UI to pick a new ava= tar name into the existing protocol and codebase is tricky. Right now I jus= t do a best attempt at parsing the first/last name. It looks for the first = " " character to split on; if that's not found it uses the whole string as = a first name along with a default last name (Guest, I think). Then it trims= the first and last name to the maximum allowable length and removes any il= legal characters. If you really want to make this support the SL use case, change the draft t= o restrict "first" and "last" to a maximum of 32 characters and only allow = alphanumeric ASCII characters. John > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, April 05, 2010 1:00 PM > To: Meadhbh Hamrick > Cc: Hurliman, John; vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? >=20 > I'm still trying to understand the use case you're trying to support. > Here's another guess: >=20 > 1. I have an agent/account with vwrap.example.com, which has assigned > me the identifier "foobar123@vwrap.example.com" and allows me to set > whatever display name I want; I pick "f00b@r" (no "firstname lastname") >=20 > 2. I want to take the agent with this identifier into SL, i.e., > authenticate to SL using that identifer. >=20 > 3. SL requires all agents to be identified / authenticated with > "Firstname Lastname" >=20 > Am I understanding the problem correctly? >=20 > If so, it seems like you could treat the "Firstname Lastname" as a > mapped identifier, with the VWRAP interface to SL (since that will > have to be new code anyway) providing the translation. > 1. When an unknown ID shows up, ask them to pick a new SL name (in UI) > 2. VWRAP layer stores binding between VWRAP ID and SL name for repeat > logins > 3. VWRAP layer authenticates client to SL as SL name >=20 > --Richard >=20 >=20 >=20 > On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: >=20 > > yes. you can have those with a single opaque identifier. the problem > > is that the large exemplar of the legacy use case does not support > > those identifiers at the moment, and it's unknown when it will in the > > future. > > > > you COULD simply say that the identifier is: > > > > first_name "dot" last_name > > > > but then what do you do with names with dots in them? change them in > > the system? use a blank? what about the names with blanks in them. > > > > i think it's an INSANELY GREAT idea to define an entity identifier > for > > agents and account holders, but at the moment and in the near term, > > there is a requirement that we carry information in a way in which > the > > first name and last name are separate items in the transfer syntax. > > > > again. there is NO REQUIREMENT that new systems support the > first_name > > / last_name semantics, but there is a requirement that it be > > representable in the protocol to support legacy systems. > > > > -cheers > > -meadhbh > > -- > > meadhbh hamrick * it's pronounced "maeve" > > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > > > > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes > > wrote: > >> Maybe I'm missing something here, but if you just had an opaque > >> "client > >> identifier" field where you could put an arbitrary name chosen by > the > >> provider, surely, then couldn't you just shove something like > >> "Firstname > >> Lastname" into that field? > >> > >> Also, wasn't there also some discussion in the meeting of > >> separating display > >> names from identifiers (as is common in IM and email systems)? > >> That way you > >> could have "Infinity Linden ". > >> > >> The only reason you would need to have a (Firstname, Lastname) pair > >> in the > >> *protocol* is if you expected a need for names to be used in that > way > >> interoperably. For example, my avatar walks into a new region > >> operated by a > >> party I've never met before, and the new region greets me by first > >> name. Is > >> that what you're thinking? > >> > >> (Even then, you could address with parsing, if this were not > >> regarded as a > >> critical use case. See Gmail's "first name extraction" in Inbox > >> message > >> summaries.) > >> > >> --Richard > >> > >> > >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > >> > >>> i thought it did for a little bit > >>> > >>> basically here's the rub. > >>> > >>> sure, we can remove this bit of SL legacy from the protocol, but > >>> linden is unlikely to drop support for it from SL. so if it's > >>> removed > >>> from the protocol, then the first name / last name option for > >>> authentication (which is currently used by both SL and OpenSim) > will > >>> need to be described in a proprietary extension to the auth spec. > >>> > >>> is this really what we want? > >>> > >>> do we really want to make it HARDER to access existing services > >>> run by > >>> organizations and individuals who are interested in making VWRAP a > >>> success? > >>> > >>> i still don't understand why keeping first name / last name as an > >>> OPTION is a problem for people. as far as i can tell, the people > who > >>> prefer this course of action are morgaine and carlo, neither of > >>> which > >>> has indicated they will be implementing this specification. > >>> > >>> calling for the removal of other people's use cases is a bit rude. > >>> while this is not an effort to "bless" linden's Second Life model > >>> and > >>> legacy protocol, it is also not an effort to bury it. > >>> > >>> the current draft allows for EITHER an account identifier or an > >>> agent > >>> identifier to be used to identify a user for the purpose of > >>> authentication. if you want to use a single opaque identifier, use > >>> the > >>> account identifier. if you want to use a first name / last name, > use > >>> the agent identifier. there is no requirement that an > authentication > >>> service support both. the requirement is, that if you support the > >>> agent identifier, you use the map defined in the draft. > >>> > >>> as it stands now, the account identifier was intended to be used in > >>> conjunction with agent identifiers in case a user had multiple > >>> avatars > >>> attached to a single "account." maybe we could change it to this: > >>> > >>> ; agent identifier > >>> > >>> &agent_identifier =3D { > >>> name: [ string, ... ] > >>> } > >>> > >>> ; account identifier > >>> > >>> &account_identifier =3D { > >>> type : 'account', > >>> agents: [ &agent_identifier, ... ], > >>> } > >>> > >>> in this proposal, the data used to identify the user is an array. > >>> for > >>> systems like second life and OpenSim that want to use two names to > >>> identify users' agents can. systems that want to use a single > >>> account > >>> name (like an email address) can. > >>> > >>> the account identifier goes back to what it was supposed to be: a > >>> way > >>> for a user with multiple avatars to login with an account > >>> credential, > >>> giving a list of agent identifiers the authentication service > should > >>> explicitly check for maintenance. > >>> > >>> so, to recap: > >>> > >>> a. please don't dis my use case. > >>> b. account identifiers actually serve a purpose other than just > >>> identifying an account, they communicate the client's interest int > >>> he > >>> maintenance state of the agents associated with the account. > >>> c. sure, i'm hip to dropping the last name / first name thing, but > >>> only if we can do something that supports our use case. (like > >>> doing a > >>> name array) > >>> d. servers shouldn't be REQUIRED to implement two string > >>> identifiers, > >>> but that being said, there are services that use them and it's > >>> probably a very good idea for clients to support this use case. > >>> > >>> -cheers > >>> -meadhbh > >>> > >>> -- > >>> meadhbh hamrick * it's pronounced "maeve" > >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >>> > >>> > >>> > >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > >>> > > >>> wrote: > >>>> > >>>> At the IETF77 meeting there was talk about removing the first > >>>> name / last > >>>> name assumptions from the avatar identifier, but it looks like > that > >>>> conversation didn't carry over to the mailing list. Does anyone > >>>> know exactly > >>>> which I-Ds (and which sections) reference avatar identifiers as > >>>> first_name+last_name? > >>>> > >>>> John > >>>> _______________________________________________ > >>>> 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 > >> > >> From ohmeadhbh@gmail.com Mon Apr 5 13:41:55 2010 Return-Path: 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 15B8228C12C for ; Mon, 5 Apr 2010 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] 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 WQuljf7cp4bP for ; Mon, 5 Apr 2010 13:41:53 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 4325F28C11B for ; Mon, 5 Apr 2010 13:41:53 -0700 (PDT) Received: by qyk11 with SMTP id 11so4348528qyk.13 for ; Mon, 05 Apr 2010 13:41:48 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1BuFF5NCpJkN+3yxvf+Z2ZVPXuSHkJbV2N/qq45K+qE=; b=aWbuysLZ3DFLlh4LVcoPbs2afiUV6TixIFl2pS03wlQ6QZH3a9lWKb2oDcJ0ZXRXpZ SD7aCTRJq7dN9zONbn0EQxx2ubVe71QJVC0sJ1n8Itxl2nFG7qaXlNswfLq1WJHiVK6t Kjw6IL2NlJydquMZ3je8mCaBXGt3nOH6kBrac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZCPKp0UpASJhQaa3l+r+AC2M7BQBCSSn9ElE9KLqcUhcIZI8HAfqYy4XKjFZc4HyTN lMbyZW5j3OLyrzEx/hO2tUN/pY+eohV3I4oV4fs3FmVXECQa4CLdxiFoQzrDOvTfN2ub uwlOQ3bjauB/flY/VtwZGE51F+609dyoXiALo= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 13:41:28 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 13:41:28 -0700 Received: by 10.229.97.207 with SMTP id m15mr10242682qcn.6.1270500108387; Mon, 05 Apr 2010 13:41:48 -0700 (PDT) Message-ID: To: Patnad Babii Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:41:55 -0000 i've seen linden's code up close. i can guarantee you i do not believe it is god incarnate. also. please do not visit my motivations. i do not tell you your reason for disagreeing with me. please do not try to tell me what my motivations are. since it wasn't clear the first time, let's go over it once more. we have a protocol that allows people to use a single string to identify a user for the purposes of authentication / authorization or two strings to identify the user. we have two existing implementations from organizations who have stated they would like to use this protocol. both use two strings at the moment. both COULD be converted to use a single identifier, and probably should, but one of them has the problem that the data is not "clean" and it would be difficult to find a programmatic mechanism to convert two strings to a single string without ambiguity. we COULD add a server in the middle that maps old SL style names to new single string identifiers, but this would require engineering effort on the two existing systems. or we could simply say, use a two string identifier or a single string identifier (your choice) and then be about our merry way. Patnad, i'm sorry you feel VWRAP is falling behind when we have a discussion about people's existing requirements. as mentioned in the charter, the VWRAP working group is NOT an effort to solve the general problem of virtual world interoperability. it is an effort to solve interoperability between systems that cooperate to present a certain style of virtual world. the MMOX mailing list is still active and is the place for discussions about interoperability between an arbitrary pair of virtual worlds. -thx -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii wrote: > Some of the people in this list seem to believe that LL code is god > re-incarnate. > > Those kind of comments seem to have hold you back for a great deal of tim= e > already. > > Those guys, John and others, don't want to remove "support" of second lif= e > in the protocol. They want to create a generic protocol that LL can (if t= hey > really wish..) use to connect to other worlds. So some adaptation will be > needed from LL side also. Like first name / last name implementation, it = can > make sense for LL but for all the rest of the internet it doesn't, look a= t > facebook for example (one great competitor isn't it...) they're not using > firstname / lastname for login but some guys at LL think its the best way= to > do it.. well.. those guys might find out their way isn't the best after a= ll > (maybe they will only find out when a whole new metaverse will be created > using VWRAP and LL is falling behind.. who knows). > > Just my 2 cents, good work guys at Intel and IBM i'll always support your > effort! > > -------------------------------------------------- > From: "Meadhbh Hamrick" > Sent: Monday, April 05, 2010 4:07 PM > To: "Hurliman, John" > Cc: > Subject: Re: [vwrap] Removing first name / last name assumptions? > >> no. we're proposing taking it off the table because there is a very >> high likelihood that are valid first and/or last names in a particular >> implementation that include spaces and periods. this is the reason we >> came up with having first_name and last_name as separate strings in >> the transfer syntax, and not a single string identifying the avatar's >> name. >> >> why do we need to REMOVE support for Second Life from this protocol? >> >> also... why do we need to define a display name when logging into the >> agent domain? shouldn't we specify one when we're rezzing an agent in >> a region? >> >> i'm hip to adding it if there's a need, but please don't remove >> support for things required for other people's implementations. >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John >> wrote: >>> >>> Agreed. My current agent domain and region domain implementations treat >>> names as opaque strings, and when it comes time to transition from the = VWRAP >>> interop protocol to the LLUDP client/server protocol I parse "First Las= t" >>> into "First" and "Last". Are we seriously considering taking this discu= ssion >>> off the table because it would be too difficult for Linden Lab to chang= e >>> their AD/RD code to parse { "display_name": "First Last" }? Last time I >>> checked, Linden Lab has not contributed any AD/RD code. IBM and the Ope= n >>> Metaverse Foundation are the ones writing all of the code for this, so = if we >>> want to talk about the hardships of organizations interested in making = this >>> a success let's ask them. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Monday, April 05, 2010 12:39 PM >>>> To: Meadhbh Hamrick >>>> Cc: Hurliman, John; vwrap@ietf.org >>>> Subject: Re: [vwrap] Removing first name / last name assumptions? >>>> >>>> Maybe I'm missing something here, but if you just had an opaque >>>> "client identifier" field where you could put an arbitrary name chosen >>>> by the provider, surely, then couldn't you just shove something like >>>> "Firstname Lastname" into that field? >>>> >>>> Also, wasn't there also some discussion in the meeting of separating >>>> display names from identifiers (as is common in IM and email >>>> systems)? =A0That way you could have "Infinity Linden >>>> >>> =A0>". >>>> >>>> The only reason you would need to have a (Firstname, Lastname) pair in >>>> the *protocol* is if you expected a need for names to be used in that >>>> way interoperably. =A0For example, my avatar walks into a new region >>>> operated by a party I've never met before, and the new region greets >>>> me by first name. =A0Is that what you're thinking? >>>> >>>> (Even then, you could address with parsing, if this were not regarded >>>> as a critical use case. =A0See Gmail's "first name extraction" in Inbo= x >>>> message summaries.) >>>> >>>> --Richard >>>> >>>> >>>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >>>> >>>> > i thought it did for a little bit >>>> > >>>> > basically here's the rub. >>>> > >>>> > sure, we can remove this bit of SL legacy from the protocol, but >>>> > linden is unlikely to drop support for it from SL. so if it's remove= d >>>> > from the protocol, then the first name / last name option for >>>> > authentication (which is currently used by both SL and OpenSim) will >>>> > need to be described in a proprietary extension to the auth spec. >>>> > >>>> > is this really what we want? >>>> > >>>> > do we really want to make it HARDER to access existing services run >>>> by >>>> > organizations and individuals who are interested in making VWRAP a >>>> > success? >>>> > >>>> > i still don't understand why keeping first name / last name as an >>>> > OPTION is a problem for people. as far as i can tell, the people who >>>> > prefer this course of action are morgaine and carlo, neither of whic= h >>>> > has indicated they will be implementing this specification. >>>> > >>>> > calling for the removal of other people's use cases is a bit rude. >>>> > while this is not an effort to "bless" linden's Second Life model an= d >>>> > legacy protocol, it is also not an effort to bury it. >>>> > >>>> > the current draft allows for EITHER an account identifier or an agen= t >>>> > identifier to be used to identify a user for the purpose of >>>> > authentication. if you want to use a single opaque identifier, use >>>> the >>>> > account identifier. if you want to use a first name / last name, use >>>> > the agent identifier. there is no requirement that an authentication >>>> > service support both. the requirement is, that if you support the >>>> > agent identifier, you use the map defined in the draft. >>>> > >>>> > as it stands now, the account identifier was intended to be used in >>>> > conjunction with agent identifiers in case a user had multiple >>>> avatars >>>> > attached to a single "account." maybe we could change it to this: >>>> > >>>> > =A0; agent identifier >>>> > >>>> > =A0&agent_identifier =3D { >>>> > =A0 =A0name: [ string, ... ] >>>> > =A0} >>>> > >>>> > =A0; account identifier >>>> > >>>> > =A0&account_identifier =3D { >>>> > =A0 =A0type : 'account', >>>> > =A0 =A0agents: [ &agent_identifier, ... ], >>>> > =A0} >>>> > >>>> > in this proposal, the data used to identify the user is an array. fo= r >>>> > systems like second life and OpenSim that want to use two names to >>>> > identify users' agents can. systems that want to use a single accoun= t >>>> > name (like an email address) can. >>>> > >>>> > the account identifier goes back to what it was supposed to be: a wa= y >>>> > for a user with multiple avatars to login with an account credential= , >>>> > giving a list of agent identifiers the authentication service should >>>> > explicitly check for maintenance. >>>> > >>>> > so, to recap: >>>> > >>>> > a. please don't dis my use case. >>>> > b. account identifiers actually serve a purpose other than just >>>> > identifying an account, they communicate the client's interest int h= e >>>> > maintenance state of the agents associated with the account. >>>> > c. sure, i'm hip to dropping the last name / first name thing, but >>>> > only if we can do something that supports our use case. (like doing = a >>>> > name array) >>>> > d. servers shouldn't be REQUIRED to implement two string identifiers= , >>>> > but that being said, there are services that use them and it's >>>> > probably a very good idea for clients to support this use case. >>>> > >>>> > -cheers >>>> > -meadhbh >>>> > >>>> > -- >>>> > meadhbh hamrick * it's pronounced "maeve" >>>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>> > >>>> > >>>> > >>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >>>> >>> > > wrote: >>>> >> At the IETF77 meeting there was talk about removing the first >>>> >> name / last name assumptions from the avatar identifier, but it >>>> >> looks like that conversation didn't carry over to the mailing list. >>>> >> Does anyone know exactly which I-Ds (and which sections) reference >>>> >> avatar identifiers as first_name+last_name? >>>> >> >>>> >> John >>>> >> _______________________________________________ >>>> >> 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 >>> >>> _______________________________________________ >>> 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 >> > From ohmeadhbh@gmail.com Mon Apr 5 13:45:38 2010 Return-Path: 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 68EFE3A69F1 for ; Mon, 5 Apr 2010 13:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 lXWCxw0D0gSV for ; Mon, 5 Apr 2010 13:45:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 773013A68AD for ; Mon, 5 Apr 2010 13:45:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1414702qwb.31 for ; Mon, 05 Apr 2010 13:45:30 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=K2YWfve7bUYEIQMdrnwFZPFm0IaEzbNDEbtCl8OZRc4=; b=YjqPfG0BM4ayxCpstr0SjisGzhWzhv4lNy5YcFW8plXADCjq5Fz1Ni27YjelqcEwPl 0k1Lz8En8dVafXa3w+5nme4L7MtKx9lS630/sjyvKVAYLSl9jI/wzuoIu4yVC1YMTZGm GXZ5Dib7FTWQrSrcR9DHnHsDqdJf4NgXWclmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=I+cfWzop2wdhrRDyNXp0x9qDgTBmO2fvh5RG7lb2LKm4z8skL+vQG/60LKR7UpcVCQ xPA6VDaZbb9edABm/KtdLFZwA8HTiehBP10Ai56CHNgJzvFFdM4jebvDnRsjgHNsbma5 TSHSKOGk/ItFaXbxqAh2/Em4gYF55vtC4ZyYw= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 13:45:09 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB738CFB@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CFB@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 13:45:09 -0700 Received: by 10.229.232.198 with SMTP id jv6mr10239481qcb.11.1270500329213; Mon, 05 Apr 2010 13:45:29 -0700 (PDT) Message-ID: To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:45:38 -0000 do you have an account on SL with the name "Reallylongfirstname...................................................... D=FCrst" ? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 1:41 PM, Hurliman, John wr= ote: > "if there's no way for a valid name to have more than 32 chars in each" > > You lost me there. Let's say my agent domain lets you create an account w= ith an identifier of "Reallylongfirstname..................................= .................... D=FCrst". Then I use Snowglobe and login to my AD/RD. = When the connection handshake completes and it's time to send UDP packets t= o the client using LLUDP I translate that name to a truncated version of th= e first name and an ASCII sanitized version of the last name so the client = has something it can display on the screen. If I try to use that same accou= nt on my AD to login to a Second Life RD, what happens? It returns an error= that that is an invalid name and I can't login, even though I followed the= spec to the letter? > > John > >> -----Original Message----- >> From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com] >> Sent: Monday, April 05, 2010 1:29 PM >> To: Hurliman, John >> Cc: Richard Barnes; vwrap@ietf.org >> Subject: Re: [vwrap] Removing first name / last name assumptions? >> >> the length thing is a good point. >> >> if we asked LL about it, i would suspect the answer we would get back >> would be: "there's no reason for that to be in the protocol, we can >> simply provide an error if someone gives an invalid name." >> >> in other words, what is the use of checking if the first name and last >> name strings are greater than 32 characters if there's no way for a >> valid name to have more than 32 chars in each? >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John >> wrote: >> > That sounds like a fine approach, but retrofitting the UI to pick a >> new avatar name into the existing protocol and codebase is tricky. >> Right now I just do a best attempt at parsing the first/last name. It >> looks for the first " " character to split on; if that's not found it >> uses the whole string as a first name along with a default last name >> (Guest, I think). Then it trims the first and last name to the maximum >> allowable length and removes any illegal characters. >> > >> > If you really want to make this support the SL use case, change the >> draft to restrict "first" and "last" to a maximum of 32 characters and >> only allow alphanumeric ASCII characters. >> > >> > John >> > >> >> -----Original Message----- >> >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> >> Sent: Monday, April 05, 2010 1:00 PM >> >> To: Meadhbh Hamrick >> >> Cc: Hurliman, John; vwrap@ietf.org >> >> Subject: Re: [vwrap] Removing first name / last name assumptions? >> >> >> >> I'm still trying to understand the use case you're trying to >> support. >> >> Here's another guess: >> >> >> >> 1. I have an agent/account with vwrap.example.com, which has >> assigned >> >> me the identifier "foobar123@vwrap.example.com" and allows me to set >> >> whatever display name I want; I pick "f00b@r" (no "firstname >> lastname") >> >> >> >> 2. I want to take the agent with this identifier into SL, i.e., >> >> authenticate to SL using that identifer. >> >> >> >> 3. SL requires all agents to be identified / authenticated with >> >> "Firstname Lastname" >> >> >> >> Am I understanding the problem correctly? >> >> >> >> If so, it seems like you could treat the "Firstname Lastname" as a >> >> mapped identifier, with the VWRAP interface to SL (since that will >> >> have to be new code anyway) providing the translation. >> >> 1. When an unknown ID shows up, ask them to pick a new SL name (in >> UI) >> >> 2. VWRAP layer stores binding between VWRAP ID and SL name for >> repeat >> >> logins >> >> 3. VWRAP layer authenticates client to SL as SL name >> >> >> >> --Richard >> >> >> >> >> >> >> >> On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: >> >> >> >> > yes. you can have those with a single opaque identifier. the >> problem >> >> > is that the large exemplar of the legacy use case does not support >> >> > those identifiers at the moment, and it's unknown when it will in >> the >> >> > future. >> >> > >> >> > you COULD simply say that the identifier is: >> >> > >> >> > first_name "dot" last_name >> >> > >> >> > but then what do you do with names with dots in them? change them >> in >> >> > the system? use a blank? what about the names with blanks in them. >> >> > >> >> > i think it's an INSANELY GREAT idea to define an entity identifier >> >> for >> >> > agents and account holders, but at the moment and in the near >> term, >> >> > there is a requirement that we carry information in a way in which >> >> the >> >> > first name and last name are separate items in the transfer >> syntax. >> >> > >> >> > again. there is NO REQUIREMENT that new systems support the >> >> first_name >> >> > / last_name semantics, but there is a requirement that it be >> >> > representable in the protocol to support legacy systems. >> >> > >> >> > -cheers >> >> > -meadhbh >> >> > -- >> >> > meadhbh hamrick * it's pronounced "maeve" >> >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> > >> >> > >> >> > >> >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes >> >> > wrote: >> >> >> Maybe I'm missing something here, but if you just had an opaque >> >> >> "client >> >> >> identifier" field where you could put an arbitrary name chosen by >> >> the >> >> >> provider, surely, then couldn't you just shove something like >> >> >> "Firstname >> >> >> Lastname" into that field? >> >> >> >> >> >> Also, wasn't there also some discussion in the meeting of >> >> >> separating display >> >> >> names from identifiers (as is common in IM and email systems)? >> >> >> That way you >> >> >> could have "Infinity Linden ". >> >> >> >> >> >> The only reason you would need to have a (Firstname, Lastname) >> pair >> >> >> in the >> >> >> *protocol* is if you expected a need for names to be used in that >> >> way >> >> >> interoperably. =A0For example, my avatar walks into a new region >> >> >> operated by a >> >> >> party I've never met before, and the new region greets me by >> first >> >> >> name. =A0Is >> >> >> that what you're thinking? >> >> >> >> >> >> (Even then, you could address with parsing, if this were not >> >> >> regarded as a >> >> >> critical use case. =A0See Gmail's "first name extraction" in Inbox >> >> >> message >> >> >> summaries.) >> >> >> >> >> >> --Richard >> >> >> >> >> >> >> >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >> >> >> >> >> >>> i thought it did for a little bit >> >> >>> >> >> >>> basically here's the rub. >> >> >>> >> >> >>> sure, we can remove this bit of SL legacy from the protocol, but >> >> >>> linden is unlikely to drop support for it from SL. so if it's >> >> >>> removed >> >> >>> from the protocol, then the first name / last name option for >> >> >>> authentication (which is currently used by both SL and OpenSim) >> >> will >> >> >>> need to be described in a proprietary extension to the auth >> spec. >> >> >>> >> >> >>> is this really what we want? >> >> >>> >> >> >>> do we really want to make it HARDER to access existing services >> >> >>> run by >> >> >>> organizations and individuals who are interested in making VWRAP >> a >> >> >>> success? >> >> >>> >> >> >>> i still don't understand why keeping first name / last name as >> an >> >> >>> OPTION is a problem for people. as far as i can tell, the people >> >> who >> >> >>> prefer this course of action are morgaine and carlo, neither of >> >> >>> which >> >> >>> has indicated they will be implementing this specification. >> >> >>> >> >> >>> calling for the removal of other people's use cases is a bit >> rude. >> >> >>> while this is not an effort to "bless" linden's Second Life >> model >> >> >>> and >> >> >>> legacy protocol, it is also not an effort to bury it. >> >> >>> >> >> >>> the current draft allows for EITHER an account identifier or an >> >> >>> agent >> >> >>> identifier to be used to identify a user for the purpose of >> >> >>> authentication. if you want to use a single opaque identifier, >> use >> >> >>> the >> >> >>> account identifier. if you want to use a first name / last name, >> >> use >> >> >>> the agent identifier. there is no requirement that an >> >> authentication >> >> >>> service support both. the requirement is, that if you support >> the >> >> >>> agent identifier, you use the map defined in the draft. >> >> >>> >> >> >>> as it stands now, the account identifier was intended to be used >> in >> >> >>> conjunction with agent identifiers in case a user had multiple >> >> >>> avatars >> >> >>> attached to a single "account." maybe we could change it to >> this: >> >> >>> >> >> >>> =A0; agent identifier >> >> >>> >> >> >>> =A0&agent_identifier =3D { >> >> >>> =A0 name: [ string, ... ] >> >> >>> =A0} >> >> >>> >> >> >>> =A0; account identifier >> >> >>> >> >> >>> =A0&account_identifier =3D { >> >> >>> =A0 type : 'account', >> >> >>> =A0 agents: [ &agent_identifier, ... ], >> >> >>> =A0} >> >> >>> >> >> >>> in this proposal, the data used to identify the user is an >> array. >> >> >>> for >> >> >>> systems like second life and OpenSim that want to use two names >> to >> >> >>> identify users' agents can. systems that want to use a single >> >> >>> account >> >> >>> name (like an email address) can. >> >> >>> >> >> >>> the account identifier goes back to what it was supposed to be: >> a >> >> >>> way >> >> >>> for a user with multiple avatars to login with an account >> >> >>> credential, >> >> >>> giving a list of agent identifiers the authentication service >> >> should >> >> >>> explicitly check for maintenance. >> >> >>> >> >> >>> so, to recap: >> >> >>> >> >> >>> a. please don't dis my use case. >> >> >>> b. account identifiers actually serve a purpose other than just >> >> >>> identifying an account, they communicate the client's interest >> int >> >> >>> he >> >> >>> maintenance state of the agents associated with the account. >> >> >>> c. sure, i'm hip to dropping the last name / first name thing, >> but >> >> >>> only if we can do something that supports our use case. (like >> >> >>> doing a >> >> >>> name array) >> >> >>> d. servers shouldn't be REQUIRED to implement two string >> >> >>> identifiers, >> >> >>> but that being said, there are services that use them and it's >> >> >>> probably a very good idea for clients to support this use case. >> >> >>> >> >> >>> -cheers >> >> >>> -meadhbh >> >> >>> >> >> >>> -- >> >> >>> meadhbh hamrick * it's pronounced "maeve" >> >> >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> >> > >> >>> > >> >> >>> wrote: >> >> >>>> >> >> >>>> At the IETF77 meeting there was talk about removing the first >> >> >>>> name / last >> >> >>>> name assumptions from the avatar identifier, but it looks like >> >> that >> >> >>>> conversation didn't carry over to the mailing list. Does anyone >> >> >>>> know exactly >> >> >>>> which I-Ds (and which sections) reference avatar identifiers as >> >> >>>> first_name+last_name? >> >> >>>> >> >> >>>> John >> >> >>>> _______________________________________________ >> >> >>>> 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 >> >> >> >> >> >> >> > >> > > From john.hurliman@intel.com Mon Apr 5 13:47:29 2010 Return-Path: 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 64CF23A6A79 for ; Mon, 5 Apr 2010 13:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 dJayEZaSapJK for ; Mon, 5 Apr 2010 13:47:28 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id CD2973A6A07 for ; Mon, 5 Apr 2010 13:47:27 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 05 Apr 2010 13:41:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,367,1267430400"; d="scan'208";a="506510312" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 05 Apr 2010 13:41:50 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Mon, 5 Apr 2010 14:41:42 -0600 From: "Hurliman, John" To: Meadhbh Hamrick Date: Mon, 5 Apr 2010 14:41:39 -0600 Thread-Topic: [vwrap] Removing first name / last name assumptions? Thread-Index: AcrU/ragyr5vbMrqQ5+hRFz4+CO7XgAAEIrQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB738CFB@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:47:29 -0000 "if there's no way for a valid name to have more than 32 chars in each" You lost me there. Let's say my agent domain lets you create an account wit= h an identifier of "Reallylongfirstname....................................= .................. D=FCrst". Then I use Snowglobe and login to my AD/RD. Wh= en the connection handshake completes and it's time to send UDP packets to = the client using LLUDP I translate that name to a truncated version of the = first name and an ASCII sanitized version of the last name so the client ha= s something it can display on the screen. If I try to use that same account= on my AD to login to a Second Life RD, what happens? It returns an error t= hat that is an invalid name and I can't login, even though I followed the s= pec to the letter? John > -----Original Message----- > From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com] > Sent: Monday, April 05, 2010 1:29 PM > To: Hurliman, John > Cc: Richard Barnes; vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? >=20 > the length thing is a good point. >=20 > if we asked LL about it, i would suspect the answer we would get back > would be: "there's no reason for that to be in the protocol, we can > simply provide an error if someone gives an invalid name." >=20 > in other words, what is the use of checking if the first name and last > name strings are greater than 32 characters if there's no way for a > valid name to have more than 32 chars in each? >=20 > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >=20 >=20 >=20 > On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John > wrote: > > That sounds like a fine approach, but retrofitting the UI to pick a > new avatar name into the existing protocol and codebase is tricky. > Right now I just do a best attempt at parsing the first/last name. It > looks for the first " " character to split on; if that's not found it > uses the whole string as a first name along with a default last name > (Guest, I think). Then it trims the first and last name to the maximum > allowable length and removes any illegal characters. > > > > If you really want to make this support the SL use case, change the > draft to restrict "first" and "last" to a maximum of 32 characters and > only allow alphanumeric ASCII characters. > > > > John > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Monday, April 05, 2010 1:00 PM > >> To: Meadhbh Hamrick > >> Cc: Hurliman, John; vwrap@ietf.org > >> Subject: Re: [vwrap] Removing first name / last name assumptions? > >> > >> I'm still trying to understand the use case you're trying to > support. > >> Here's another guess: > >> > >> 1. I have an agent/account with vwrap.example.com, which has > assigned > >> me the identifier "foobar123@vwrap.example.com" and allows me to set > >> whatever display name I want; I pick "f00b@r" (no "firstname > lastname") > >> > >> 2. I want to take the agent with this identifier into SL, i.e., > >> authenticate to SL using that identifer. > >> > >> 3. SL requires all agents to be identified / authenticated with > >> "Firstname Lastname" > >> > >> Am I understanding the problem correctly? > >> > >> If so, it seems like you could treat the "Firstname Lastname" as a > >> mapped identifier, with the VWRAP interface to SL (since that will > >> have to be new code anyway) providing the translation. > >> 1. When an unknown ID shows up, ask them to pick a new SL name (in > UI) > >> 2. VWRAP layer stores binding between VWRAP ID and SL name for > repeat > >> logins > >> 3. VWRAP layer authenticates client to SL as SL name > >> > >> --Richard > >> > >> > >> > >> On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: > >> > >> > yes. you can have those with a single opaque identifier. the > problem > >> > is that the large exemplar of the legacy use case does not support > >> > those identifiers at the moment, and it's unknown when it will in > the > >> > future. > >> > > >> > you COULD simply say that the identifier is: > >> > > >> > first_name "dot" last_name > >> > > >> > but then what do you do with names with dots in them? change them > in > >> > the system? use a blank? what about the names with blanks in them. > >> > > >> > i think it's an INSANELY GREAT idea to define an entity identifier > >> for > >> > agents and account holders, but at the moment and in the near > term, > >> > there is a requirement that we carry information in a way in which > >> the > >> > first name and last name are separate items in the transfer > syntax. > >> > > >> > again. there is NO REQUIREMENT that new systems support the > >> first_name > >> > / last_name semantics, but there is a requirement that it be > >> > representable in the protocol to support legacy systems. > >> > > >> > -cheers > >> > -meadhbh > >> > -- > >> > meadhbh hamrick * it's pronounced "maeve" > >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> > > >> > > >> > > >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes > >> > wrote: > >> >> Maybe I'm missing something here, but if you just had an opaque > >> >> "client > >> >> identifier" field where you could put an arbitrary name chosen by > >> the > >> >> provider, surely, then couldn't you just shove something like > >> >> "Firstname > >> >> Lastname" into that field? > >> >> > >> >> Also, wasn't there also some discussion in the meeting of > >> >> separating display > >> >> names from identifiers (as is common in IM and email systems)? > >> >> That way you > >> >> could have "Infinity Linden ". > >> >> > >> >> The only reason you would need to have a (Firstname, Lastname) > pair > >> >> in the > >> >> *protocol* is if you expected a need for names to be used in that > >> way > >> >> interoperably. =A0For example, my avatar walks into a new region > >> >> operated by a > >> >> party I've never met before, and the new region greets me by > first > >> >> name. =A0Is > >> >> that what you're thinking? > >> >> > >> >> (Even then, you could address with parsing, if this were not > >> >> regarded as a > >> >> critical use case. =A0See Gmail's "first name extraction" in Inbox > >> >> message > >> >> summaries.) > >> >> > >> >> --Richard > >> >> > >> >> > >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > >> >> > >> >>> i thought it did for a little bit > >> >>> > >> >>> basically here's the rub. > >> >>> > >> >>> sure, we can remove this bit of SL legacy from the protocol, but > >> >>> linden is unlikely to drop support for it from SL. so if it's > >> >>> removed > >> >>> from the protocol, then the first name / last name option for > >> >>> authentication (which is currently used by both SL and OpenSim) > >> will > >> >>> need to be described in a proprietary extension to the auth > spec. > >> >>> > >> >>> is this really what we want? > >> >>> > >> >>> do we really want to make it HARDER to access existing services > >> >>> run by > >> >>> organizations and individuals who are interested in making VWRAP > a > >> >>> success? > >> >>> > >> >>> i still don't understand why keeping first name / last name as > an > >> >>> OPTION is a problem for people. as far as i can tell, the people > >> who > >> >>> prefer this course of action are morgaine and carlo, neither of > >> >>> which > >> >>> has indicated they will be implementing this specification. > >> >>> > >> >>> calling for the removal of other people's use cases is a bit > rude. > >> >>> while this is not an effort to "bless" linden's Second Life > model > >> >>> and > >> >>> legacy protocol, it is also not an effort to bury it. > >> >>> > >> >>> the current draft allows for EITHER an account identifier or an > >> >>> agent > >> >>> identifier to be used to identify a user for the purpose of > >> >>> authentication. if you want to use a single opaque identifier, > use > >> >>> the > >> >>> account identifier. if you want to use a first name / last name, > >> use > >> >>> the agent identifier. there is no requirement that an > >> authentication > >> >>> service support both. the requirement is, that if you support > the > >> >>> agent identifier, you use the map defined in the draft. > >> >>> > >> >>> as it stands now, the account identifier was intended to be used > in > >> >>> conjunction with agent identifiers in case a user had multiple > >> >>> avatars > >> >>> attached to a single "account." maybe we could change it to > this: > >> >>> > >> >>> =A0; agent identifier > >> >>> > >> >>> =A0&agent_identifier =3D { > >> >>> =A0 name: [ string, ... ] > >> >>> =A0} > >> >>> > >> >>> =A0; account identifier > >> >>> > >> >>> =A0&account_identifier =3D { > >> >>> =A0 type : 'account', > >> >>> =A0 agents: [ &agent_identifier, ... ], > >> >>> =A0} > >> >>> > >> >>> in this proposal, the data used to identify the user is an > array. > >> >>> for > >> >>> systems like second life and OpenSim that want to use two names > to > >> >>> identify users' agents can. systems that want to use a single > >> >>> account > >> >>> name (like an email address) can. > >> >>> > >> >>> the account identifier goes back to what it was supposed to be: > a > >> >>> way > >> >>> for a user with multiple avatars to login with an account > >> >>> credential, > >> >>> giving a list of agent identifiers the authentication service > >> should > >> >>> explicitly check for maintenance. > >> >>> > >> >>> so, to recap: > >> >>> > >> >>> a. please don't dis my use case. > >> >>> b. account identifiers actually serve a purpose other than just > >> >>> identifying an account, they communicate the client's interest > int > >> >>> he > >> >>> maintenance state of the agents associated with the account. > >> >>> c. sure, i'm hip to dropping the last name / first name thing, > but > >> >>> only if we can do something that supports our use case. (like > >> >>> doing a > >> >>> name array) > >> >>> d. servers shouldn't be REQUIRED to implement two string > >> >>> identifiers, > >> >>> but that being said, there are services that use them and it's > >> >>> probably a very good idea for clients to support this use case. > >> >>> > >> >>> -cheers > >> >>> -meadhbh > >> >>> > >> >>> -- > >> >>> meadhbh hamrick * it's pronounced "maeve" > >> >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> >>> > >> >>> > >> >>> > >> >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > >> >> >>> > > >> >>> wrote: > >> >>>> > >> >>>> At the IETF77 meeting there was talk about removing the first > >> >>>> name / last > >> >>>> name assumptions from the avatar identifier, but it looks like > >> that > >> >>>> conversation didn't carry over to the mailing list. Does anyone > >> >>>> know exactly > >> >>>> which I-Ds (and which sections) reference avatar identifiers as > >> >>>> first_name+last_name? > >> >>>> > >> >>>> John > >> >>>> _______________________________________________ > >> >>>> 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 > >> >> > >> >> > > > > From john.hurliman@intel.com Mon Apr 5 13:48:01 2010 Return-Path: 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 3D3523A6A79 for ; Mon, 5 Apr 2010 13:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 ov-3pydgfO9e for ; Mon, 5 Apr 2010 13:47:59 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 609A83A6A07 for ; Mon, 5 Apr 2010 13:47:59 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 05 Apr 2010 13:47:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,367,1267430400"; d="scan'208";a="262268380" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 05 Apr 2010 13:47:55 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Mon, 5 Apr 2010 14:47:47 -0600 From: "Hurliman, John" To: Meadhbh Hamrick Date: Mon, 5 Apr 2010 14:47:44 -0600 Thread-Topic: [vwrap] Removing first name / last name assumptions? Thread-Index: AcrVAPyqiKpEAuYwT0qCbFy+7QOP8gAAAdGw Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB738D0A@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CC5@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738CFB@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:48:01 -0000 No, this account is not on SL. It is on the SimianGrid Testing Agent Domain= , hosted at . John > -----Original Message----- > From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com] > Sent: Monday, April 05, 2010 1:45 PM > To: Hurliman, John > Cc: Richard Barnes; vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? >=20 > do you have an account on SL with the name > "Reallylongfirstname................................................... > ... > D=FCrst" ? >=20 > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >=20 >=20 >=20 > On Mon, Apr 5, 2010 at 1:41 PM, Hurliman, John > wrote: > > "if there's no way for a valid name to have more than 32 chars in > each" > > > > You lost me there. Let's say my agent domain lets you create an > account with an identifier of > "Reallylongfirstname................................................... > ... D=FCrst". Then I use Snowglobe and login to my AD/RD. When the > connection handshake completes and it's time to send UDP packets to the > client using LLUDP I translate that name to a truncated version of the > first name and an ASCII sanitized version of the last name so the > client has something it can display on the screen. If I try to use that > same account on my AD to login to a Second Life RD, what happens? It > returns an error that that is an invalid name and I can't login, even > though I followed the spec to the letter? > > > > John > > > >> -----Original Message----- > >> From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com] > >> Sent: Monday, April 05, 2010 1:29 PM > >> To: Hurliman, John > >> Cc: Richard Barnes; vwrap@ietf.org > >> Subject: Re: [vwrap] Removing first name / last name assumptions? > >> > >> the length thing is a good point. > >> > >> if we asked LL about it, i would suspect the answer we would get > back > >> would be: "there's no reason for that to be in the protocol, we can > >> simply provide an error if someone gives an invalid name." > >> > >> in other words, what is the use of checking if the first name and > last > >> name strings are greater than 32 characters if there's no way for a > >> valid name to have more than 32 chars in each? > >> > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> > >> > >> > >> On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John > >> wrote: > >> > That sounds like a fine approach, but retrofitting the UI to pick > a > >> new avatar name into the existing protocol and codebase is tricky. > >> Right now I just do a best attempt at parsing the first/last name. > It > >> looks for the first " " character to split on; if that's not found > it > >> uses the whole string as a first name along with a default last name > >> (Guest, I think). Then it trims the first and last name to the > maximum > >> allowable length and removes any illegal characters. > >> > > >> > If you really want to make this support the SL use case, change > the > >> draft to restrict "first" and "last" to a maximum of 32 characters > and > >> only allow alphanumeric ASCII characters. > >> > > >> > John > >> > > >> >> -----Original Message----- > >> >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> >> Sent: Monday, April 05, 2010 1:00 PM > >> >> To: Meadhbh Hamrick > >> >> Cc: Hurliman, John; vwrap@ietf.org > >> >> Subject: Re: [vwrap] Removing first name / last name assumptions? > >> >> > >> >> I'm still trying to understand the use case you're trying to > >> support. > >> >> Here's another guess: > >> >> > >> >> 1. I have an agent/account with vwrap.example.com, which has > >> assigned > >> >> me the identifier "foobar123@vwrap.example.com" and allows me to > set > >> >> whatever display name I want; I pick "f00b@r" (no "firstname > >> lastname") > >> >> > >> >> 2. I want to take the agent with this identifier into SL, i.e., > >> >> authenticate to SL using that identifer. > >> >> > >> >> 3. SL requires all agents to be identified / authenticated with > >> >> "Firstname Lastname" > >> >> > >> >> Am I understanding the problem correctly? > >> >> > >> >> If so, it seems like you could treat the "Firstname Lastname" as > a > >> >> mapped identifier, with the VWRAP interface to SL (since that > will > >> >> have to be new code anyway) providing the translation. > >> >> 1. When an unknown ID shows up, ask them to pick a new SL name > (in > >> UI) > >> >> 2. VWRAP layer stores binding between VWRAP ID and SL name for > >> repeat > >> >> logins > >> >> 3. VWRAP layer authenticates client to SL as SL name > >> >> > >> >> --Richard > >> >> > >> >> > >> >> > >> >> On Apr 5, 2010, at 3:46 PM, Meadhbh Hamrick wrote: > >> >> > >> >> > yes. you can have those with a single opaque identifier. the > >> problem > >> >> > is that the large exemplar of the legacy use case does not > support > >> >> > those identifiers at the moment, and it's unknown when it will > in > >> the > >> >> > future. > >> >> > > >> >> > you COULD simply say that the identifier is: > >> >> > > >> >> > first_name "dot" last_name > >> >> > > >> >> > but then what do you do with names with dots in them? change > them > >> in > >> >> > the system? use a blank? what about the names with blanks in > them. > >> >> > > >> >> > i think it's an INSANELY GREAT idea to define an entity > identifier > >> >> for > >> >> > agents and account holders, but at the moment and in the near > >> term, > >> >> > there is a requirement that we carry information in a way in > which > >> >> the > >> >> > first name and last name are separate items in the transfer > >> syntax. > >> >> > > >> >> > again. there is NO REQUIREMENT that new systems support the > >> >> first_name > >> >> > / last_name semantics, but there is a requirement that it be > >> >> > representable in the protocol to support legacy systems. > >> >> > > >> >> > -cheers > >> >> > -meadhbh > >> >> > -- > >> >> > meadhbh hamrick * it's pronounced "maeve" > >> >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> >> > > >> >> > > >> >> > > >> >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes > > >> >> > wrote: > >> >> >> Maybe I'm missing something here, but if you just had an > opaque > >> >> >> "client > >> >> >> identifier" field where you could put an arbitrary name chosen > by > >> >> the > >> >> >> provider, surely, then couldn't you just shove something like > >> >> >> "Firstname > >> >> >> Lastname" into that field? > >> >> >> > >> >> >> Also, wasn't there also some discussion in the meeting of > >> >> >> separating display > >> >> >> names from identifiers (as is common in IM and email systems)? > >> >> >> That way you > >> >> >> could have "Infinity Linden ". > >> >> >> > >> >> >> The only reason you would need to have a (Firstname, Lastname) > >> pair > >> >> >> in the > >> >> >> *protocol* is if you expected a need for names to be used in > that > >> >> way > >> >> >> interoperably. =A0For example, my avatar walks into a new region > >> >> >> operated by a > >> >> >> party I've never met before, and the new region greets me by > >> first > >> >> >> name. =A0Is > >> >> >> that what you're thinking? > >> >> >> > >> >> >> (Even then, you could address with parsing, if this were not > >> >> >> regarded as a > >> >> >> critical use case. =A0See Gmail's "first name extraction" in > Inbox > >> >> >> message > >> >> >> summaries.) > >> >> >> > >> >> >> --Richard > >> >> >> > >> >> >> > >> >> >> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > >> >> >> > >> >> >>> i thought it did for a little bit > >> >> >>> > >> >> >>> basically here's the rub. > >> >> >>> > >> >> >>> sure, we can remove this bit of SL legacy from the protocol, > but > >> >> >>> linden is unlikely to drop support for it from SL. so if it's > >> >> >>> removed > >> >> >>> from the protocol, then the first name / last name option for > >> >> >>> authentication (which is currently used by both SL and > OpenSim) > >> >> will > >> >> >>> need to be described in a proprietary extension to the auth > >> spec. > >> >> >>> > >> >> >>> is this really what we want? > >> >> >>> > >> >> >>> do we really want to make it HARDER to access existing > services > >> >> >>> run by > >> >> >>> organizations and individuals who are interested in making > VWRAP > >> a > >> >> >>> success? > >> >> >>> > >> >> >>> i still don't understand why keeping first name / last name > as > >> an > >> >> >>> OPTION is a problem for people. as far as i can tell, the > people > >> >> who > >> >> >>> prefer this course of action are morgaine and carlo, neither > of > >> >> >>> which > >> >> >>> has indicated they will be implementing this specification. > >> >> >>> > >> >> >>> calling for the removal of other people's use cases is a bit > >> rude. > >> >> >>> while this is not an effort to "bless" linden's Second Life > >> model > >> >> >>> and > >> >> >>> legacy protocol, it is also not an effort to bury it. > >> >> >>> > >> >> >>> the current draft allows for EITHER an account identifier or > an > >> >> >>> agent > >> >> >>> identifier to be used to identify a user for the purpose of > >> >> >>> authentication. if you want to use a single opaque > identifier, > >> use > >> >> >>> the > >> >> >>> account identifier. if you want to use a first name / last > name, > >> >> use > >> >> >>> the agent identifier. there is no requirement that an > >> >> authentication > >> >> >>> service support both. the requirement is, that if you support > >> the > >> >> >>> agent identifier, you use the map defined in the draft. > >> >> >>> > >> >> >>> as it stands now, the account identifier was intended to be > used > >> in > >> >> >>> conjunction with agent identifiers in case a user had > multiple > >> >> >>> avatars > >> >> >>> attached to a single "account." maybe we could change it to > >> this: > >> >> >>> > >> >> >>> =A0; agent identifier > >> >> >>> > >> >> >>> =A0&agent_identifier =3D { > >> >> >>> =A0 name: [ string, ... ] > >> >> >>> =A0} > >> >> >>> > >> >> >>> =A0; account identifier > >> >> >>> > >> >> >>> =A0&account_identifier =3D { > >> >> >>> =A0 type : 'account', > >> >> >>> =A0 agents: [ &agent_identifier, ... ], > >> >> >>> =A0} > >> >> >>> > >> >> >>> in this proposal, the data used to identify the user is an > >> array. > >> >> >>> for > >> >> >>> systems like second life and OpenSim that want to use two > names > >> to > >> >> >>> identify users' agents can. systems that want to use a single > >> >> >>> account > >> >> >>> name (like an email address) can. > >> >> >>> > >> >> >>> the account identifier goes back to what it was supposed to > be: > >> a > >> >> >>> way > >> >> >>> for a user with multiple avatars to login with an account > >> >> >>> credential, > >> >> >>> giving a list of agent identifiers the authentication service > >> >> should > >> >> >>> explicitly check for maintenance. > >> >> >>> > >> >> >>> so, to recap: > >> >> >>> > >> >> >>> a. please don't dis my use case. > >> >> >>> b. account identifiers actually serve a purpose other than > just > >> >> >>> identifying an account, they communicate the client's > interest > >> int > >> >> >>> he > >> >> >>> maintenance state of the agents associated with the account. > >> >> >>> c. sure, i'm hip to dropping the last name / first name > thing, > >> but > >> >> >>> only if we can do something that supports our use case. (like > >> >> >>> doing a > >> >> >>> name array) > >> >> >>> d. servers shouldn't be REQUIRED to implement two string > >> >> >>> identifiers, > >> >> >>> but that being said, there are services that use them and > it's > >> >> >>> probably a very good idea for clients to support this use > case. > >> >> >>> > >> >> >>> -cheers > >> >> >>> -meadhbh > >> >> >>> > >> >> >>> -- > >> >> >>> meadhbh hamrick * it's pronounced "maeve" > >> >> >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > >> >> >> >> >>> > > >> >> >>> wrote: > >> >> >>>> > >> >> >>>> At the IETF77 meeting there was talk about removing the > first > >> >> >>>> name / last > >> >> >>>> name assumptions from the avatar identifier, but it looks > like > >> >> that > >> >> >>>> conversation didn't carry over to the mailing list. Does > anyone > >> >> >>>> know exactly > >> >> >>>> which I-Ds (and which sections) reference avatar identifiers > as > >> >> >>>> first_name+last_name? > >> >> >>>> > >> >> >>>> John > >> >> >>>> _______________________________________________ > >> >> >>>> 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 > >> >> >> > >> >> >> > >> > > >> > > > From vaughn.deluca@gmail.com Mon Apr 5 15:24:46 2010 Return-Path: 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 2D9F23A6A1E for ; Mon, 5 Apr 2010 15:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 TTYrri0VEtJd for ; Mon, 5 Apr 2010 15:24:43 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 687973A69ED for ; Mon, 5 Apr 2010 15:21:26 -0700 (PDT) Received: by ewy24 with SMTP id 24so1196386ewy.33 for ; Mon, 05 Apr 2010 15:21:20 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=JcczMsV2xvwm7R/UIlAhgSQzINZsSr8HqFCXm2PaHuw=; b=D1SmD8Gp4HuPzKoQ3YpinQCPJdiScCl9ezk8PHFQhn7SO1FKkBBKkdpAob0VlVSmU0 atxwYcOycQzCXG+Ydu0L3kQ6EnSo+VkR2QkvbAeFEBxnn/Oy/2Yk9mfxciGcGVmb1VWN Y3JHSVXrjiglfo3QlYBD3rDDJbkCD28ksg2sQ= 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=dBUElMITaeblAkM84L6wfzz73VmWZgBkYY3DTzHRhWZpThJhezPx9OLYdMhzJq4NmD gDOJZ/h5AlYByZZf8LiPdYCB+blp4+2Afvbn3UWqn4DrqyxAXu87EfUbz+EZCJP7khJW FYmYReZ7Eta49FCi2e7aChvorKDqEU/4O70V8= MIME-Version: 1.0 Received: by 10.213.105.136 with HTTP; Mon, 5 Apr 2010 15:21:20 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> Date: Tue, 6 Apr 2010 00:21:20 +0200 Received: by 10.213.39.196 with SMTP id h4mr1729597ebe.97.1270506080158; Mon, 05 Apr 2010 15:21:20 -0700 (PDT) Message-ID: From: Vaughn Deluca To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=00148531a91a97fd06048384bfb6 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 22:24:46 -0000 --00148531a91a97fd06048384bfb6 Content-Type: text/plain; charset=ISO-8859-1 I agree with meadhbh on this one. I have not seen any good arguments explaining why a first name/last name option would be harmful. --Vaughn On Mon, Apr 5, 2010 at 10:41 PM, Meadhbh Hamrick wrote: > i've seen linden's code up close. i can guarantee you i do not believe > it is god incarnate. > > also. please do not visit my motivations. i do not tell you your > reason for disagreeing with me. please do not try to tell me what my > motivations are. > > since it wasn't clear the first time, let's go over it once more. > > we have a protocol that allows people to use a single string to > identify a user for the purposes of authentication / authorization or > two strings to identify the user. > > we have two existing implementations from organizations who have > stated they would like to use this protocol. both use two strings at > the moment. both COULD be converted to use a single identifier, and > probably should, but one of them has the problem that the data is not > "clean" and it would be difficult to find a programmatic mechanism to > convert two strings to a single string without ambiguity. > > we COULD add a server in the middle that maps old SL style names to > new single string identifiers, but this would require engineering > effort on the two existing systems. > > or we could simply say, use a two string identifier or a single string > identifier (your choice) and then be about our merry way. > > Patnad, i'm sorry you feel VWRAP is falling behind when we have a > discussion about people's existing requirements. as mentioned in the > charter, the VWRAP working group is NOT an effort to solve the general > problem of virtual world interoperability. it is an effort to solve > interoperability between systems that cooperate to present a certain > style of virtual world. > > the MMOX mailing list is still active and is the place for discussions > about interoperability between an arbitrary pair of virtual worlds. > > -thx > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii wrote: > > Some of the people in this list seem to believe that LL code is god > > re-incarnate. > > > > Those kind of comments seem to have hold you back for a great deal of > time > > already. > > > > Those guys, John and others, don't want to remove "support" of second > life > > in the protocol. They want to create a generic protocol that LL can (if > they > > really wish..) use to connect to other worlds. So some adaptation will be > > needed from LL side also. Like first name / last name implementation, it > can > > make sense for LL but for all the rest of the internet it doesn't, look > at > > facebook for example (one great competitor isn't it...) they're not using > > firstname / lastname for login but some guys at LL think its the best way > to > > do it.. well.. those guys might find out their way isn't the best after > all > > (maybe they will only find out when a whole new metaverse will be created > > using VWRAP and LL is falling behind.. who knows). > > > > Just my 2 cents, good work guys at Intel and IBM i'll always support your > > effort! > > > > -------------------------------------------------- > > From: "Meadhbh Hamrick" > > Sent: Monday, April 05, 2010 4:07 PM > > To: "Hurliman, John" > > Cc: > > Subject: Re: [vwrap] Removing first name / last name assumptions? > > > >> no. we're proposing taking it off the table because there is a very > >> high likelihood that are valid first and/or last names in a particular > >> implementation that include spaces and periods. this is the reason we > >> came up with having first_name and last_name as separate strings in > >> the transfer syntax, and not a single string identifying the avatar's > >> name. > >> > >> why do we need to REMOVE support for Second Life from this protocol? > >> > >> also... why do we need to define a display name when logging into the > >> agent domain? shouldn't we specify one when we're rezzing an agent in > >> a region? > >> > >> i'm hip to adding it if there's a need, but please don't remove > >> support for things required for other people's implementations. > >> > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> > >> > >> > >> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John < > john.hurliman@intel.com> > >> wrote: > >>> > >>> Agreed. My current agent domain and region domain implementations treat > >>> names as opaque strings, and when it comes time to transition from the > VWRAP > >>> interop protocol to the LLUDP client/server protocol I parse "First > Last" > >>> into "First" and "Last". Are we seriously considering taking this > discussion > >>> off the table because it would be too difficult for Linden Lab to > change > >>> their AD/RD code to parse { "display_name": "First Last" }? Last time I > >>> checked, Linden Lab has not contributed any AD/RD code. IBM and the > Open > >>> Metaverse Foundation are the ones writing all of the code for this, so > if we > >>> want to talk about the hardships of organizations interested in making > this > >>> a success let's ask them. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] > >>>> Sent: Monday, April 05, 2010 12:39 PM > >>>> To: Meadhbh Hamrick > >>>> Cc: Hurliman, John; vwrap@ietf.org > >>>> Subject: Re: [vwrap] Removing first name / last name assumptions? > >>>> > >>>> Maybe I'm missing something here, but if you just had an opaque > >>>> "client identifier" field where you could put an arbitrary name chosen > >>>> by the provider, surely, then couldn't you just shove something like > >>>> "Firstname Lastname" into that field? > >>>> > >>>> Also, wasn't there also some discussion in the meeting of separating > >>>> display names from identifiers (as is common in IM and email > >>>> systems)? That way you could have "Infinity Linden > >>>> >>>> >". > >>>> > >>>> The only reason you would need to have a (Firstname, Lastname) pair in > >>>> the *protocol* is if you expected a need for names to be used in that > >>>> way interoperably. For example, my avatar walks into a new region > >>>> operated by a party I've never met before, and the new region greets > >>>> me by first name. Is that what you're thinking? > >>>> > >>>> (Even then, you could address with parsing, if this were not regarded > >>>> as a critical use case. See Gmail's "first name extraction" in Inbox > >>>> message summaries.) > >>>> > >>>> --Richard > >>>> > >>>> > >>>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: > >>>> > >>>> > i thought it did for a little bit > >>>> > > >>>> > basically here's the rub. > >>>> > > >>>> > sure, we can remove this bit of SL legacy from the protocol, but > >>>> > linden is unlikely to drop support for it from SL. so if it's > removed > >>>> > from the protocol, then the first name / last name option for > >>>> > authentication (which is currently used by both SL and OpenSim) will > >>>> > need to be described in a proprietary extension to the auth spec. > >>>> > > >>>> > is this really what we want? > >>>> > > >>>> > do we really want to make it HARDER to access existing services run > >>>> by > >>>> > organizations and individuals who are interested in making VWRAP a > >>>> > success? > >>>> > > >>>> > i still don't understand why keeping first name / last name as an > >>>> > OPTION is a problem for people. as far as i can tell, the people who > >>>> > prefer this course of action are morgaine and carlo, neither of > which > >>>> > has indicated they will be implementing this specification. > >>>> > > >>>> > calling for the removal of other people's use cases is a bit rude. > >>>> > while this is not an effort to "bless" linden's Second Life model > and > >>>> > legacy protocol, it is also not an effort to bury it. > >>>> > > >>>> > the current draft allows for EITHER an account identifier or an > agent > >>>> > identifier to be used to identify a user for the purpose of > >>>> > authentication. if you want to use a single opaque identifier, use > >>>> the > >>>> > account identifier. if you want to use a first name / last name, use > >>>> > the agent identifier. there is no requirement that an authentication > >>>> > service support both. the requirement is, that if you support the > >>>> > agent identifier, you use the map defined in the draft. > >>>> > > >>>> > as it stands now, the account identifier was intended to be used in > >>>> > conjunction with agent identifiers in case a user had multiple > >>>> avatars > >>>> > attached to a single "account." maybe we could change it to this: > >>>> > > >>>> > ; agent identifier > >>>> > > >>>> > &agent_identifier = { > >>>> > name: [ string, ... ] > >>>> > } > >>>> > > >>>> > ; account identifier > >>>> > > >>>> > &account_identifier = { > >>>> > type : 'account', > >>>> > agents: [ &agent_identifier, ... ], > >>>> > } > >>>> > > >>>> > in this proposal, the data used to identify the user is an array. > for > >>>> > systems like second life and OpenSim that want to use two names to > >>>> > identify users' agents can. systems that want to use a single > account > >>>> > name (like an email address) can. > >>>> > > >>>> > the account identifier goes back to what it was supposed to be: a > way > >>>> > for a user with multiple avatars to login with an account > credential, > >>>> > giving a list of agent identifiers the authentication service should > >>>> > explicitly check for maintenance. > >>>> > > >>>> > so, to recap: > >>>> > > >>>> > a. please don't dis my use case. > >>>> > b. account identifiers actually serve a purpose other than just > >>>> > identifying an account, they communicate the client's interest int > he > >>>> > maintenance state of the agents associated with the account. > >>>> > c. sure, i'm hip to dropping the last name / first name thing, but > >>>> > only if we can do something that supports our use case. (like doing > a > >>>> > name array) > >>>> > d. servers shouldn't be REQUIRED to implement two string > identifiers, > >>>> > but that being said, there are services that use them and it's > >>>> > probably a very good idea for clients to support this use case. > >>>> > > >>>> > -cheers > >>>> > -meadhbh > >>>> > > >>>> > -- > >>>> > meadhbh hamrick * it's pronounced "maeve" > >>>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >>>> > > >>>> > > >>>> > > >>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John > >>>> >>>> > > wrote: > >>>> >> At the IETF77 meeting there was talk about removing the first > >>>> >> name / last name assumptions from the avatar identifier, but it > >>>> >> looks like that conversation didn't carry over to the mailing list. > >>>> >> Does anyone know exactly which I-Ds (and which sections) reference > >>>> >> avatar identifiers as first_name+last_name? > >>>> >> > >>>> >> John > >>>> >> _______________________________________________ > >>>> >> 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 > >>> > >>> _______________________________________________ > >>> 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 > >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00148531a91a97fd06048384bfb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I ag= ree with meadhbh on this one. =A0I have not seen any good arguments explain= ing why a first name/last name option would be harmful.
--Vaughn
<= /span>
On Mon, Apr 5, 2010 at 10:41 PM, Meadhbh Hamrick= <ohmeadhbh@gma= il.com> wrote:
i've seen linden's code up close. i can guarantee you i do not beli= eve
it is god incarnate.

also. please do not visit my motivations. i do not tell you your
reason for disagreeing with me. please do not try to tell me what my
motivations are.

since it wasn't clear the first time, let's go over it once more.
we have a protocol that allows people to use a single string to
identify a user for the purposes of authentication / authorization or
two strings to identify the user.

we have two existing implementations from organizations who have
stated they would like to use this protocol. both use two strings at
the moment. both COULD be converted to use a single identifier, and
probably should, but one of them has the problem that the data is not
"clean" and it would be difficult to find a programmatic mechanis= m to
convert two strings to a single string without ambiguity.

we COULD add a server in the middle that maps old SL style names to
new single string identifiers, but this would require engineering
effort on the two existing systems.

or we could simply say, use a two string identifier or a single string
identifier (your choice) and then be about our merry way.

Patnad, i'm sorry you feel VWRAP is falling behind when we have a
discussion about people's existing requirements. as mentioned in the charter, the VWRAP working group is NOT an effort to solve the general
problem of virtual world interoperability. it is an effort to solve
interoperability between systems that cooperate to present a certain
style of virtual world.

the MMOX mailing list is still active and is the place for discussions
about interoperability between an arbitrary pair of virtual worlds.

-thx
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Mon, Apr 5, 2010 at 1:17 PM, Pat= nad Babii <djshag@hotmail.com&= gt; wrote:
> Some of the people in this list seem to believe that LL code is god > re-incarnate.
>
> Those kind of comments seem to have hold you back for a great deal of = time
> already.
>
> Those guys, John and others, don't want to remove "support&qu= ot; of second life
> in the protocol. They want to create a generic protocol that LL can (i= f they
> really wish..) use to connect to other worlds. So some adaptation will= be
> needed from LL side also. Like first name / last name implementation, = it can
> make sense for LL but for all the rest of the internet it doesn't,= look at
> facebook for example (one great competitor isn't it...) they'r= e not using
> firstname / lastname for login but some guys at LL think its the best = way to
> do it.. well.. those guys might find out their way isn't the best = after all
> (maybe they will only find out when a whole new metaverse will be crea= ted
> using VWRAP and LL is falling behind.. who knows).
>
> Just my 2 cents, good work guys at Intel and IBM i'll always suppo= rt your
> effort!
>
> --------------------------------------------------
> From: "Meadhbh Hamrick" <ohmeadhbh@gmail.com>
> Sent: Monday, April 05, 2010 4:07 PM
> To: "Hurliman, John" <john.hurliman@intel.com>
> Cc: <vwrap@ietf.org>
> Subject: Re: [vwrap] Removing first name / last name assumptions?
>
>> no. we're proposing taking it off the table because there is a= very
>> high likelihood that are valid first and/or last names in a partic= ular
>> implementation that include spaces and periods. this is the reason= we
>> came up with having first_name and last_name as separate strings i= n
>> the transfer syntax, and not a single string identifying the avata= r's
>> name.
>>
>> why do we need to REMOVE support for Second Life from this protoco= l?
>>
>> also... why do we need to define a display name when logging into = the
>> agent domain? shouldn't we specify one when we're rezzing = an agent in
>> a region?
>>
>> i'm hip to adding it if there's a need, but please don'= ;t remove
>> support for things required for other people's implementations= .
>>
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * htt= p://meadhbh.org/ * OhMeadhbh@gma= il.com
>>
>>
>>
>> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John <john.hurliman@intel.com>
>> wrote:
>>>
>>> Agreed. My current agent domain and region domain implementati= ons treat
>>> names as opaque strings, and when it comes time to transition = from the VWRAP
>>> interop protocol to the LLUDP client/server protocol I parse &= quot;First Last"
>>> into "First" and "Last". Are we seriously = considering taking this discussion
>>> off the table because it would be too difficult for Linden Lab= to change
>>> their AD/RD code to parse { "display_name": "Fi= rst Last" }? Last time I
>>> checked, Linden Lab has not contributed any AD/RD code. IBM an= d the Open
>>> Metaverse Foundation are the ones writing all of the code for = this, so if we
>>> want to talk about the hardships of organizations interested i= n making this
>>> a success let's ask them.
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>>>> Sent: Monday, April 05, 2010 12:39 PM
>>>> To: Meadhbh Hamrick
>>>> Cc: Hurliman, John; vwra= p@ietf.org
>>>> Subject: Re: [vwrap] Removing first name / last name assum= ptions?
>>>>
>>>> Maybe I'm missing something here, but if you just had = an opaque
>>>> "client identifier" field where you could put an= arbitrary name chosen
>>>> by the provider, surely, then couldn't you just shove = something like
>>>> "Firstname Lastname" into that field?
>>>>
>>>> Also, wasn't there also some discussion in the meeting= of separating
>>>> display names from identifiers (as is common in IM and ema= il
>>>> systems)? =A0That way you could have "Infinity Linden=
>>>> <infinity@examp= le.com
>>>> =A0>".
>>>>
>>>> The only reason you would need to have a (Firstname, Lastn= ame) pair in
>>>> the *protocol* is if you expected a need for names to be u= sed in that
>>>> way interoperably. =A0For example, my avatar walks into a = new region
>>>> operated by a party I've never met before, and the new= region greets
>>>> me by first name. =A0Is that what you're thinking?
>>>>
>>>> (Even then, you could address with parsing, if this were n= ot regarded
>>>> as a critical use case. =A0See Gmail's "first nam= e extraction" in Inbox
>>>> message summaries.)
>>>>
>>>> --Richard
>>>>
>>>>
>>>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote:
>>>>
>>>> > i thought it did for a little bit
>>>> >
>>>> > basically here's the rub.
>>>> >
>>>> > sure, we can remove this bit of SL legacy from the pr= otocol, but
>>>> > linden is unlikely to drop support for it from SL. so= if it's removed
>>>> > from the protocol, then the first name / last name op= tion for
>>>> > authentication (which is currently used by both SL an= d OpenSim) will
>>>> > need to be described in a proprietary extension to th= e auth spec.
>>>> >
>>>> > is this really what we want?
>>>> >
>>>> > do we really want to make it HARDER to access existin= g services run
>>>> by
>>>> > organizations and individuals who are interested in m= aking VWRAP a
>>>> > success?
>>>> >
>>>> > i still don't understand why keeping first name /= last name as an
>>>> > OPTION is a problem for people. as far as i can tell,= the people who
>>>> > prefer this course of action are morgaine and carlo, = neither of which
>>>> > has indicated they will be implementing this specific= ation.
>>>> >
>>>> > calling for the removal of other people's use cas= es is a bit rude.
>>>> > while this is not an effort to "bless" lind= en's Second Life model and
>>>> > legacy protocol, it is also not an effort to bury it.=
>>>> >
>>>> > the current draft allows for EITHER an account identi= fier or an agent
>>>> > identifier to be used to identify a user for the purp= ose of
>>>> > authentication. if you want to use a single opaque id= entifier, use
>>>> the
>>>> > account identifier. if you want to use a first name /= last name, use
>>>> > the agent identifier. there is no requirement that an= authentication
>>>> > service support both. the requirement is, that if you= support the
>>>> > agent identifier, you use the map defined in the draf= t.
>>>> >
>>>> > as it stands now, the account identifier was intended= to be used in
>>>> > conjunction with agent identifiers in case a user had= multiple
>>>> avatars
>>>> > attached to a single "account." maybe we co= uld change it to this:
>>>> >
>>>> > =A0; agent identifier
>>>> >
>>>> > =A0&agent_identifier =3D {
>>>> > =A0 =A0name: [ string, ... ]
>>>> > =A0}
>>>> >
>>>> > =A0; account identifier
>>>> >
>>>> > =A0&account_identifier =3D {
>>>> > =A0 =A0type : 'account',
>>>> > =A0 =A0agents: [ &agent_identifier, ... ],
>>>> > =A0}
>>>> >
>>>> > in this proposal, the data used to identify the user = is an array. for
>>>> > systems like second life and OpenSim that want to use= two names to
>>>> > identify users' agents can. systems that want to = use a single account
>>>> > name (like an email address) can.
>>>> >
>>>> > the account identifier goes back to what it was suppo= sed to be: a way
>>>> > for a user with multiple avatars to login with an acc= ount credential,
>>>> > giving a list of agent identifiers the authentication= service should
>>>> > explicitly check for maintenance.
>>>> >
>>>> > so, to recap:
>>>> >
>>>> > a. please don't dis my use case.
>>>> > b. account identifiers actually serve a purpose other= than just
>>>> > identifying an account, they communicate the client&#= 39;s interest int he
>>>> > maintenance state of the agents associated with the a= ccount.
>>>> > c. sure, i'm hip to dropping the last name / firs= t name thing, but
>>>> > only if we can do something that supports our use cas= e. (like doing a
>>>> > name array)
>>>> > d. servers shouldn't be REQUIRED to implement two= string identifiers,
>>>> > but that being said, there are services that use them= and it's
>>>> > probably a very good idea for clients to support this= use case.
>>>> >
>>>> > -cheers
>>>> > -meadhbh
>>>> >
>>>> > --
>>>> > meadhbh hamrick * it's pronounced "maeve&quo= t;
>>>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John
>>>> <john.hurlim= an@intel.com
>>>> > > wrote:
>>>> >> At the IETF77 meeting there was talk about removi= ng the first
>>>> >> name / last name assumptions from the avatar iden= tifier, but it
>>>> >> looks like that conversation didn't carry ove= r to the mailing list.
>>>> >> Does anyone know exactly which I-Ds (and which se= ctions) reference
>>>> >> avatar identifiers as first_name+last_name?
>>>> >>
>>>> >> John
>>>> >> _______________________________________________ >>>> >> vwrap mailing list
>>>> >> vwrap@ietf.org<= /a>
>>>> >> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>
>>>> > _______________________________________________
>>>> > vwrap mailing list
>>>> > vwrap@ietf.org<= br> >>>> > https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>> _______________________________________________
>>> 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
>>
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00148531a91a97fd06048384bfb6-- From morgaine.dinova@googlemail.com Mon Apr 5 20:21:38 2010 Return-Path: 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 7114F3A67CC for ; Mon, 5 Apr 2010 20:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sXEHy5rMAfOM for ; Mon, 5 Apr 2010 20:21:34 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id C793A3A67B6 for ; Mon, 5 Apr 2010 20:21:30 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so266061eyf.51 for ; Mon, 05 Apr 2010 20:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=i4p0VlNRMQPps74BdZOf62txQ0/xmlAhW/MvF6EFygk=; b=MFcJQezMIglbUKcEdqb/JYRrNkyVVwI6W92C+bhUSo6lhpewqV8Dlus1+a+PCMO8j4 0D9rFGOyC4JsePfCQLUZdPRbRUbkfiy8lcA0TJIgCAwj6Kkuq1XcHum09SGMynVAkhEE eNS+qyTvaT1O3fJTqZTnlsrbQ7nNKNIk4oa2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WbiJBmjCgUPNNo2OBL6ciHjYWxVe6FmBGhMwwzJ4CAjnx2M1d9KddVVqT+989uGYnX LUF7GXVrO7kYccY084tQcAM838KleWGB9U0F4SW61GDLmPmhwyN7b+EsXDfqaFlp9K5F eUWmGUqdQoqxl2Z0qQnmcM34vikRVDuubWwuA= MIME-Version: 1.0 Received: by 10.213.105.66 with HTTP; Mon, 5 Apr 2010 20:21:24 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> Date: Tue, 6 Apr 2010 04:21:24 +0100 Received: by 10.213.68.11 with SMTP id t11mr3526581ebi.98.1270524084780; Mon, 05 Apr 2010 20:21:24 -0700 (PDT) Message-ID: From: Morgaine To: Vaughn Deluca Content-Type: multipart/alternative; boundary=00c09ffb5200c07f60048388f037 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 03:21:38 -0000 --00c09ffb5200c07f60048388f037 Content-Type: text/plain; charset=ISO-8859-1 Vaughn, Internet protocols aren't designed at the IETF on the basis of favoring some existing provider. The Mission Statement and Tao of the IETF place a higher burden than that on us. We're working to the benefit of all the users on the Internet, and that's why we try to make protocols that are generic and free of special cases. SL's two-part name is that service's particular choice, but it is not generic, nor is it helpful to the world as a whole. A single field is generic, because it can hold any number of words, and whitespace is the normal separator in human writing. We're proposing something better than the legacy service, rather than merely accepting something that is "not harmful". And one might validly reason that a 2-part name is indeed "harmful" to the genericity of the protocol, because it is a special case that may not apply to others. In any event, parsing a single field and accepting only 2-word names within it is such a trivial task that I'm surprised to find anyone arguing otherwise. Some providers may allow only single words, some two, others may allow only three words of which the first is a title, and others may allow an arbitrary number of words as is common in gaming worlds. The generic approach is to use a single field in the protocol and to parse it as required for the local service. Note that Joshua Linden wrote a very thoughtful post on this subject last June, noting that {firstname, lastname} is just "*a quirk of Second Life, and not necessarily something that every OGP provider must use*" -- here . That's a perfectly fine quirk for SL, but quirks have no place in the protocol when we have the better option of a generic single name field. SL can just parse the single field for words and reject anything except two-word names. It's not rocket science, and we have far tougher problems than that to solve ahead of us. Morgaine. ================================ On Mon, Apr 5, 2010 at 11:21 PM, Vaughn Deluca wrote: > I agree with meadhbh on this one. I have not seen any good arguments > explaining why a first name/last name option would be harmful. > --Vaughn > > On Mon, Apr 5, 2010 at 10:41 PM, Meadhbh Hamrick wrote: > >> i've seen linden's code up close. i can guarantee you i do not believe >> it is god incarnate. >> >> also. please do not visit my motivations. i do not tell you your >> reason for disagreeing with me. please do not try to tell me what my >> motivations are. >> >> since it wasn't clear the first time, let's go over it once more. >> >> we have a protocol that allows people to use a single string to >> identify a user for the purposes of authentication / authorization or >> two strings to identify the user. >> >> we have two existing implementations from organizations who have >> stated they would like to use this protocol. both use two strings at >> the moment. both COULD be converted to use a single identifier, and >> probably should, but one of them has the problem that the data is not >> "clean" and it would be difficult to find a programmatic mechanism to >> convert two strings to a single string without ambiguity. >> >> we COULD add a server in the middle that maps old SL style names to >> new single string identifiers, but this would require engineering >> effort on the two existing systems. >> >> or we could simply say, use a two string identifier or a single string >> identifier (your choice) and then be about our merry way. >> >> Patnad, i'm sorry you feel VWRAP is falling behind when we have a >> discussion about people's existing requirements. as mentioned in the >> charter, the VWRAP working group is NOT an effort to solve the general >> problem of virtual world interoperability. it is an effort to solve >> interoperability between systems that cooperate to present a certain >> style of virtual world. >> >> the MMOX mailing list is still active and is the place for discussions >> about interoperability between an arbitrary pair of virtual worlds. >> >> -thx >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii wrote: >> > Some of the people in this list seem to believe that LL code is god >> > re-incarnate. >> > >> > Those kind of comments seem to have hold you back for a great deal of >> time >> > already. >> > >> > Those guys, John and others, don't want to remove "support" of second >> life >> > in the protocol. They want to create a generic protocol that LL can (if >> they >> > really wish..) use to connect to other worlds. So some adaptation will >> be >> > needed from LL side also. Like first name / last name implementation, it >> can >> > make sense for LL but for all the rest of the internet it doesn't, look >> at >> > facebook for example (one great competitor isn't it...) they're not >> using >> > firstname / lastname for login but some guys at LL think its the best >> way to >> > do it.. well.. those guys might find out their way isn't the best after >> all >> > (maybe they will only find out when a whole new metaverse will be >> created >> > using VWRAP and LL is falling behind.. who knows). >> > >> > Just my 2 cents, good work guys at Intel and IBM i'll always support >> your >> > effort! >> > >> > -------------------------------------------------- >> > From: "Meadhbh Hamrick" >> > Sent: Monday, April 05, 2010 4:07 PM >> > To: "Hurliman, John" >> > Cc: >> > Subject: Re: [vwrap] Removing first name / last name assumptions? >> > >> >> no. we're proposing taking it off the table because there is a very >> >> high likelihood that are valid first and/or last names in a particular >> >> implementation that include spaces and periods. this is the reason we >> >> came up with having first_name and last_name as separate strings in >> >> the transfer syntax, and not a single string identifying the avatar's >> >> name. >> >> >> >> why do we need to REMOVE support for Second Life from this protocol? >> >> >> >> also... why do we need to define a display name when logging into the >> >> agent domain? shouldn't we specify one when we're rezzing an agent in >> >> a region? >> >> >> >> i'm hip to adding it if there's a need, but please don't remove >> >> support for things required for other people's implementations. >> >> >> >> -- >> >> meadhbh hamrick * it's pronounced "maeve" >> >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> >> >> >> >> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John < >> john.hurliman@intel.com> >> >> wrote: >> >>> >> >>> Agreed. My current agent domain and region domain implementations >> treat >> >>> names as opaque strings, and when it comes time to transition from the >> VWRAP >> >>> interop protocol to the LLUDP client/server protocol I parse "First >> Last" >> >>> into "First" and "Last". Are we seriously considering taking this >> discussion >> >>> off the table because it would be too difficult for Linden Lab to >> change >> >>> their AD/RD code to parse { "display_name": "First Last" }? Last time >> I >> >>> checked, Linden Lab has not contributed any AD/RD code. IBM and the >> Open >> >>> Metaverse Foundation are the ones writing all of the code for this, so >> if we >> >>> want to talk about the hardships of organizations interested in making >> this >> >>> a success let's ask them. >> >>> >> >>> John >> >>> >> >>>> -----Original Message----- >> >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >> >>>> Sent: Monday, April 05, 2010 12:39 PM >> >>>> To: Meadhbh Hamrick >> >>>> Cc: Hurliman, John; vwrap@ietf.org >> >>>> Subject: Re: [vwrap] Removing first name / last name assumptions? >> >>>> >> >>>> Maybe I'm missing something here, but if you just had an opaque >> >>>> "client identifier" field where you could put an arbitrary name >> chosen >> >>>> by the provider, surely, then couldn't you just shove something like >> >>>> "Firstname Lastname" into that field? >> >>>> >> >>>> Also, wasn't there also some discussion in the meeting of separating >> >>>> display names from identifiers (as is common in IM and email >> >>>> systems)? That way you could have "Infinity Linden >> >>>> > >>>> >". >> >>>> >> >>>> The only reason you would need to have a (Firstname, Lastname) pair >> in >> >>>> the *protocol* is if you expected a need for names to be used in that >> >>>> way interoperably. For example, my avatar walks into a new region >> >>>> operated by a party I've never met before, and the new region greets >> >>>> me by first name. Is that what you're thinking? >> >>>> >> >>>> (Even then, you could address with parsing, if this were not regarded >> >>>> as a critical use case. See Gmail's "first name extraction" in Inbox >> >>>> message summaries.) >> >>>> >> >>>> --Richard >> >>>> >> >>>> >> >>>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote: >> >>>> >> >>>> > i thought it did for a little bit >> >>>> > >> >>>> > basically here's the rub. >> >>>> > >> >>>> > sure, we can remove this bit of SL legacy from the protocol, but >> >>>> > linden is unlikely to drop support for it from SL. so if it's >> removed >> >>>> > from the protocol, then the first name / last name option for >> >>>> > authentication (which is currently used by both SL and OpenSim) >> will >> >>>> > need to be described in a proprietary extension to the auth spec. >> >>>> > >> >>>> > is this really what we want? >> >>>> > >> >>>> > do we really want to make it HARDER to access existing services run >> >>>> by >> >>>> > organizations and individuals who are interested in making VWRAP a >> >>>> > success? >> >>>> > >> >>>> > i still don't understand why keeping first name / last name as an >> >>>> > OPTION is a problem for people. as far as i can tell, the people >> who >> >>>> > prefer this course of action are morgaine and carlo, neither of >> which >> >>>> > has indicated they will be implementing this specification. >> >>>> > >> >>>> > calling for the removal of other people's use cases is a bit rude. >> >>>> > while this is not an effort to "bless" linden's Second Life model >> and >> >>>> > legacy protocol, it is also not an effort to bury it. >> >>>> > >> >>>> > the current draft allows for EITHER an account identifier or an >> agent >> >>>> > identifier to be used to identify a user for the purpose of >> >>>> > authentication. if you want to use a single opaque identifier, use >> >>>> the >> >>>> > account identifier. if you want to use a first name / last name, >> use >> >>>> > the agent identifier. there is no requirement that an >> authentication >> >>>> > service support both. the requirement is, that if you support the >> >>>> > agent identifier, you use the map defined in the draft. >> >>>> > >> >>>> > as it stands now, the account identifier was intended to be used in >> >>>> > conjunction with agent identifiers in case a user had multiple >> >>>> avatars >> >>>> > attached to a single "account." maybe we could change it to this: >> >>>> > >> >>>> > ; agent identifier >> >>>> > >> >>>> > &agent_identifier = { >> >>>> > name: [ string, ... ] >> >>>> > } >> >>>> > >> >>>> > ; account identifier >> >>>> > >> >>>> > &account_identifier = { >> >>>> > type : 'account', >> >>>> > agents: [ &agent_identifier, ... ], >> >>>> > } >> >>>> > >> >>>> > in this proposal, the data used to identify the user is an array. >> for >> >>>> > systems like second life and OpenSim that want to use two names to >> >>>> > identify users' agents can. systems that want to use a single >> account >> >>>> > name (like an email address) can. >> >>>> > >> >>>> > the account identifier goes back to what it was supposed to be: a >> way >> >>>> > for a user with multiple avatars to login with an account >> credential, >> >>>> > giving a list of agent identifiers the authentication service >> should >> >>>> > explicitly check for maintenance. >> >>>> > >> >>>> > so, to recap: >> >>>> > >> >>>> > a. please don't dis my use case. >> >>>> > b. account identifiers actually serve a purpose other than just >> >>>> > identifying an account, they communicate the client's interest int >> he >> >>>> > maintenance state of the agents associated with the account. >> >>>> > c. sure, i'm hip to dropping the last name / first name thing, but >> >>>> > only if we can do something that supports our use case. (like doing >> a >> >>>> > name array) >> >>>> > d. servers shouldn't be REQUIRED to implement two string >> identifiers, >> >>>> > but that being said, there are services that use them and it's >> >>>> > probably a very good idea for clients to support this use case. >> >>>> > >> >>>> > -cheers >> >>>> > -meadhbh >> >>>> > >> >>>> > -- >> >>>> > meadhbh hamrick * it's pronounced "maeve" >> >>>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >>>> > >> >>>> > >> >>>> > >> >>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John >> >>>> > >>>> > > wrote: >> >>>> >> At the IETF77 meeting there was talk about removing the first >> >>>> >> name / last name assumptions from the avatar identifier, but it >> >>>> >> looks like that conversation didn't carry over to the mailing >> list. >> >>>> >> Does anyone know exactly which I-Ds (and which sections) reference >> >>>> >> avatar identifiers as first_name+last_name? >> >>>> >> >> >>>> >> John >> >>>> >> _______________________________________________ >> >>>> >> 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 >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> _______________________________________________ >> 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 > > --00c09ffb5200c07f60048388f037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn, Internet protocols aren't designed at the IETF on the basis of = favoring some existing provider.=A0 The Mission Statement and Tao of the IE= TF place a higher burden than that on us.=A0 We're working to the benef= it of all the users on the Internet, and that's why we try to make prot= ocols that are generic and free of special cases.

SL's two-part name is that service's particular choice, but it = is not generic, nor is it helpful to the world as a whole.=A0 A single fiel= d is generic, because it can hold any number of words, and whitespace is th= e normal separator in human writing.

We're proposing something better than the legacy service, rather th= an merely accepting something that is "not harmful".=A0 And one m= ight validly reason that a 2-part name is indeed "harmful" to the= genericity of the protocol, because it is a special case that may not appl= y to others.

In any event, parsing a single field and accepting only 2-word names wi= thin it is such a trivial task that I'm surprised to find anyone arguin= g otherwise.=A0 Some providers may allow only single words, some two, other= s may allow only three words of which the first is a title, and others may = allow an arbitrary number of words as is common in gaming worlds.=A0 The ge= neric approach is to use a single field in the protocol and to parse it as = required for the local service.

Note that Joshua Linden wrote a very thoughtful post on this subject la= st June, noting that {firstname, lastname} is just "a quirk of Seco= nd Life, and not necessarily something that every OGP provider must use= " -- here.

That's a perfectly fine quirk for SL, but quirks have no place in t= he protocol when we have the better option of a generic single name field.= =A0 SL can just parse the single field for words and reject anything except= two-word names.=A0 It's not rocket science, and we have far tougher pr= oblems than that to solve ahead of us.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Apr 5, 2010 at 11:21 PM, Vaughn Deluca <vaughn.deluca@gmai= l.com> wrote:
I agree with meadhbh on this one. =A0I have not s= een any good arguments explaining why a first name/last name option would b= e harmful.
--Vaughn

On Mon, Apr 5, 2010 at 10:41 PM, Meadhbh Hamrick= <ohmeadhbh@gmail.com> wrote:
i've seen linden's code up close. i can guarantee you i do not beli= eve
it is god incarnate.

also. please do not visit my motivations. i do not tell you your
reason for disagreeing with me. please do not try to tell me what my
motivations are.

since it wasn't clear the first time, let's go over it once more.
we have a protocol that allows people to use a single string to
identify a user for the purposes of authentication / authorization or
two strings to identify the user.

we have two existing implementations from organizations who have
stated they would like to use this protocol. both use two strings at
the moment. both COULD be converted to use a single identifier, and
probably should, but one of them has the problem that the data is not
"clean" and it would be difficult to find a programmatic mechanis= m to
convert two strings to a single string without ambiguity.

we COULD add a server in the middle that maps old SL style names to
new single string identifiers, but this would require engineering
effort on the two existing systems.

or we could simply say, use a two string identifier or a single string
identifier (your choice) and then be about our merry way.

Patnad, i'm sorry you feel VWRAP is falling behind when we have a
discussion about people's existing requirements. as mentioned in the charter, the VWRAP working group is NOT an effort to solve the general
problem of virtual world interoperability. it is an effort to solve
interoperability between systems that cooperate to present a certain
style of virtual world.

the MMOX mailing list is still active and is the place for discussions
about interoperability between an arbitrary pair of virtual worlds.

-thx
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMe= adhbh@gmail.com



On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii <= ;djshag@hotmail.com= > wrote:
> Some of the people in this list seem to believe that LL code is god > re-incarnate.
>
> Those kind of comments seem to have hold you back for a great deal of = time
> already.
>
> Those guys, John and others, don't want to remove "support&qu= ot; of second life
> in the protocol. They want to create a generic protocol that LL can (i= f they
> really wish..) use to connect to other worlds. So some adaptation will= be
> needed from LL side also. Like first name / last name implementation, = it can
> make sense for LL but for all the rest of the internet it doesn't,= look at
> facebook for example (one great competitor isn't it...) they'r= e not using
> firstname / lastname for login but some guys at LL think its the best = way to
> do it.. well.. those guys might find out their way isn't the best = after all
> (maybe they will only find out when a whole new metaverse will be crea= ted
> using VWRAP and LL is falling behind.. who knows).
>
> Just my 2 cents, good work guys at Intel and IBM i'll always suppo= rt your
> effort!
>
> --------------------------------------------------
> From: "Meadhbh Hamrick" <ohmeadhbh@gmail.com>
> Sent: Monday, April 05, 2010 4:07 PM
> To: "Hurliman, John" <john.hurliman@intel.com>
> Cc: <vwrap@ietf= .org>
> Subject: Re: [vwrap] Removing first name / last name assumptions?
>
>> no. we're proposing taking it off the table because there is a= very
>> high likelihood that are valid first and/or last names in a partic= ular
>> implementation that include spaces and periods. this is the reason= we
>> came up with having first_name and last_name as separate strings i= n
>> the transfer syntax, and not a single string identifying the avata= r's
>> name.
>>
>> why do we need to REMOVE support for Second Life from this protoco= l?
>>
>> also... why do we need to define a display name when logging into = the
>> agent domain? shouldn't we specify one when we're rezzing = an agent in
>> a region?
>>
>> i'm hip to adding it if there's a need, but please don'= ;t remove
>> support for things required for other people's implementations= .
>>
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * htt= p://meadhbh.org/ * OhMeadhbh@gmail.com
>>
>>
>>
>> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John <john.hurliman@intel.com&= gt;
>> wrote:
>>>
>>> Agreed. My current agent domain and region domain implementati= ons treat
>>> names as opaque strings, and when it comes time to transition = from the VWRAP
>>> interop protocol to the LLUDP client/server protocol I parse &= quot;First Last"
>>> into "First" and "Last". Are we seriously = considering taking this discussion
>>> off the table because it would be too difficult for Linden Lab= to change
>>> their AD/RD code to parse { "display_name": "Fi= rst Last" }? Last time I
>>> checked, Linden Lab has not contributed any AD/RD code. IBM an= d the Open
>>> Metaverse Foundation are the ones writing all of the code for = this, so if we
>>> want to talk about the hardships of organizations interested i= n making this
>>> a success let's ask them.
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>>>> Sent: Monday, April 05, 2010 12:39 PM
>>>> To: Meadhbh Hamrick
>>>> Cc: Hurliman, John; vwrap@ietf.org
>>>> Subject: Re: [vwrap] Removing first name / last name assum= ptions?
>>>>
>>>> Maybe I'm missing something here, but if you just had = an opaque
>>>> "client identifier" field where you could put an= arbitrary name chosen
>>>> by the provider, surely, then couldn't you just shove = something like
>>>> "Firstname Lastname" into that field?
>>>>
>>>> Also, wasn't there also some discussion in the meeting= of separating
>>>> display names from identifiers (as is common in IM and ema= il
>>>> systems)? =A0That way you could have "Infinity Linden=
>>>> <infinity@example.com
>>>> =A0>".
>>>>
>>>> The only reason you would need to have a (Firstname, Lastn= ame) pair in
>>>> the *protocol* is if you expected a need for names to be u= sed in that
>>>> way interoperably. =A0For example, my avatar walks into a = new region
>>>> operated by a party I've never met before, and the new= region greets
>>>> me by first name. =A0Is that what you're thinking?
>>>>
>>>> (Even then, you could address with parsing, if this were n= ot regarded
>>>> as a critical use case. =A0See Gmail's "first nam= e extraction" in Inbox
>>>> message summaries.)
>>>>
>>>> --Richard
>>>>
>>>>
>>>> On Apr 5, 2010, at 3:20 PM, Meadhbh Hamrick wrote:
>>>>
>>>> > i thought it did for a little bit
>>>> >
>>>> > basically here's the rub.
>>>> >
>>>> > sure, we can remove this bit of SL legacy from the pr= otocol, but
>>>> > linden is unlikely to drop support for it from SL. so= if it's removed
>>>> > from the protocol, then the first name / last name op= tion for
>>>> > authentication (which is currently used by both SL an= d OpenSim) will
>>>> > need to be described in a proprietary extension to th= e auth spec.
>>>> >
>>>> > is this really what we want?
>>>> >
>>>> > do we really want to make it HARDER to access existin= g services run
>>>> by
>>>> > organizations and individuals who are interested in m= aking VWRAP a
>>>> > success?
>>>> >
>>>> > i still don't understand why keeping first name /= last name as an
>>>> > OPTION is a problem for people. as far as i can tell,= the people who
>>>> > prefer this course of action are morgaine and carlo, = neither of which
>>>> > has indicated they will be implementing this specific= ation.
>>>> >
>>>> > calling for the removal of other people's use cas= es is a bit rude.
>>>> > while this is not an effort to "bless" lind= en's Second Life model and
>>>> > legacy protocol, it is also not an effort to bury it.=
>>>> >
>>>> > the current draft allows for EITHER an account identi= fier or an agent
>>>> > identifier to be used to identify a user for the purp= ose of
>>>> > authentication. if you want to use a single opaque id= entifier, use
>>>> the
>>>> > account identifier. if you want to use a first name /= last name, use
>>>> > the agent identifier. there is no requirement that an= authentication
>>>> > service support both. the requirement is, that if you= support the
>>>> > agent identifier, you use the map defined in the draf= t.
>>>> >
>>>> > as it stands now, the account identifier was intended= to be used in
>>>> > conjunction with agent identifiers in case a user had= multiple
>>>> avatars
>>>> > attached to a single "account." maybe we co= uld change it to this:
>>>> >
>>>> > =A0; agent identifier
>>>> >
>>>> > =A0&agent_identifier =3D {
>>>> > =A0 =A0name: [ string, ... ]
>>>> > =A0}
>>>> >
>>>> > =A0; account identifier
>>>> >
>>>> > =A0&account_identifier =3D {
>>>> > =A0 =A0type : 'account',
>>>> > =A0 =A0agents: [ &agent_identifier, ... ],
>>>> > =A0}
>>>> >
>>>> > in this proposal, the data used to identify the user = is an array. for
>>>> > systems like second life and OpenSim that want to use= two names to
>>>> > identify users' agents can. systems that want to = use a single account
>>>> > name (like an email address) can.
>>>> >
>>>> > the account identifier goes back to what it was suppo= sed to be: a way
>>>> > for a user with multiple avatars to login with an acc= ount credential,
>>>> > giving a list of agent identifiers the authentication= service should
>>>> > explicitly check for maintenance.
>>>> >
>>>> > so, to recap:
>>>> >
>>>> > a. please don't dis my use case.
>>>> > b. account identifiers actually serve a purpose other= than just
>>>> > identifying an account, they communicate the client&#= 39;s interest int he
>>>> > maintenance state of the agents associated with the a= ccount.
>>>> > c. sure, i'm hip to dropping the last name / firs= t name thing, but
>>>> > only if we can do something that supports our use cas= e. (like doing a
>>>> > name array)
>>>> > d. servers shouldn't be REQUIRED to implement two= string identifiers,
>>>> > but that being said, there are services that use them= and it's
>>>> > probably a very good idea for clients to support this= use case.
>>>> >
>>>> > -cheers
>>>> > -meadhbh
>>>> >
>>>> > --
>>>> > meadhbh hamrick * it's pronounced "maeve&quo= t;
>>>> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John
>>>> <john.hurliman@intel.com
>>>> > > wrote:
>>>> >> At the IETF77 meeting there was talk about removi= ng the first
>>>> >> name / last name assumptions from the avatar iden= tifier, but it
>>>> >> looks like that conversation didn't carry ove= r to the mailing list.
>>>> >> Does anyone know exactly which I-Ds (and which se= ctions) reference
>>>> >> avatar identifiers as first_name+last_name?
>>>> >>
>>>> >> John
>>>> >> _______________________________________________ >>>> >> vwrap mailing list
>>>> >> vwrap@ietf.org
>>>> >> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>
>>>> > _______________________________________________
>>>> > vwrap mailing list
>>>> > v= wrap@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>> _______________________________________________
>>> 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
>>
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--00c09ffb5200c07f60048388f037-- From barryleiba.mailing.lists@gmail.com Mon Apr 5 21:32:15 2010 Return-Path: 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 7155A3A6A55 for ; Mon, 5 Apr 2010 21:32:15 -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 AXeksrTydJib for ; Mon, 5 Apr 2010 21:32:14 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 3A2A13A67CC for ; Mon, 5 Apr 2010 21:32:14 -0700 (PDT) Received: by fxm27 with SMTP id 27so1678491fxm.28 for ; Mon, 05 Apr 2010 21:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:content-type; bh=aZ1j/oFEEo3O0GoqMZnuYL+6tE2Dz7Fc1kcNWYt0e3k=; b=LocFmWrkvPvcwB0xAd3c/DYHWtOy3c8P/jY+yYXDMIuPj6pKDyT2JFLuS7ioPfieox uHiY6+NPZUDq/Y1ZiFhsAKFkIwuFMdZhg4L+0NdB8AxFwQNojVvNQkG/CvCabJ717DXL 8h7lVI2Uza0coGP3i4ANE9y60Wt31pEYzcl5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=xSH5eUMVD8jzBKPMOV36WdNVVOJAjdqwT6hOzzpvuRwSfnQniN6oNed2l7MRJr4I/X wCqQSrUNhXubTOpstRfAbOllsWbuHdf7HZPG2LxDH11WX3ueFgW/t9nDs88RjTP6XL/B YkubWx4KhBtqpfdypnke9HkY5LPp/oRbqXFKw= MIME-Version: 1.0 Received: by 10.223.112.15 with HTTP; Mon, 5 Apr 2010 21:32:08 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> Date: Tue, 6 Apr 2010 00:32:08 -0400 Received: by 10.223.7.91 with SMTP id c27mr6748979fac.19.1270528328083; Mon, 05 Apr 2010 21:32:08 -0700 (PDT) Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 04:32:15 -0000 On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick wrote: > no. we're proposing taking it off the table because there is a very > high likelihood that are valid first and/or last names in a particular > implementation that include spaces and periods. this is the reason we > came up with having first_name and last_name as separate strings in > the transfer syntax, and not a single string identifying the avatar's > name. > > why do we need to REMOVE support for Second Life from this protocol? Well, here's the thing: First: I've spent a lot of years designing protocols, and I think it's a terrible idea to define a specific artifact of a specific implementation in a new protocol. We've done it many times before, and it's pretty much always caused problems. Sometimes those problems eventually worked themselves out, but I'm quite sure it was a mistake to go there. Second: I don't see it as a question of "removing support for Second Life", but one of looking at alternatives that are protocol-clean and allow everyone to work with it. And, by the way, I don't consider two separate identifier fields, from which you're meant to pick which you want to use, to be "protocol-clean". Why not define the agent identifier in a self-parsing way? Something like this should work (written in ABNF): agent-identifier := delim 1*(id-part delim) id-part = string delim = 1char ...where the idea is that the delimiter is a single character that appears as the first character (so it's self-identifying), and then between ID parts. The implementation would pick a character (which could be a non-printable code point, such as 0x00 or 0x01, if necessary) that doesn't appear in any identifier part. Here's a sampling of agent-identifiers, each within quotes just to make it clear where they start and end: " Joshua Linden " ".Joshua.Linden." (another way to represent the same thing) "/Joshua/Linden/" (a third) "XJoshuaXLindenX" (a fourth) " Melanie " (an identifier with just one part) "rMelanier" (the same, in another representation) ".Melanie." (or less weirdly) " Barak Hussein Obama " (here's one with three parts) "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit if you're old enough to know who he is) "~le roy~barr~" (Meadhbh's example with an embedded blank) This scheme only adds two characters to the identifier (the leading and trailing delimiter, and we *could* eliminate the trailing one, if people prefer, by defining agent-identifier as "1*(delim id-part)"... I like having it), and seems to solve everyone's problem. Barry, as participant From ohmeadhbh@gmail.com Mon Apr 5 22:02:10 2010 Return-Path: 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 B53543A6862 for ; Mon, 5 Apr 2010 22:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] 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 VoHiTkLSJ6MV for ; Mon, 5 Apr 2010 22:02:09 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 55B783A685D for ; Mon, 5 Apr 2010 22:02:09 -0700 (PDT) Received: by qyk11 with SMTP id 11so4707957qyk.13 for ; Mon, 05 Apr 2010 22:02:04 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Sq5BKHgm37sj4xZsTVL2Rzi9M0VvbYmo55W+N/1gu/4=; b=xq9KQ1uPia+aaYjQeENTSQT0JE8QbrDs1IYkGpaf+w4bltp8kghd6gvmgyLOAgAM0h iGeILsmnwLdtPeJypmQRojS0eLPwz/Gjotxg+IRq0aQnMEFt0cV/0DFkBu2eSWxcY2ZA HKrFTrS+7RaPaFT+DD9UlBNSKNdqIaV1C4mic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=e+8PWT1hyKO/WVsnZjpVUnyHW7I5Q/kHqdWJWwu2k/IqrdOIXs/TYhuGUOoJmpmHPR gu8++BmF8Ew6MDjjwBgXcl2sLft3mCFH94pJYDX2/GRAsL6dZ3LhBUROJ7Fr0oSCMy14 fnVcU9eVBN931mmkVEhz9zKelvZ+i1Iwq6uRg= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Mon, 5 Apr 2010 22:01:44 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Mon, 5 Apr 2010 22:01:44 -0700 Received: by 10.229.91.16 with SMTP id k16mr10748752qcm.40.1270530124124; Mon, 05 Apr 2010 22:02:04 -0700 (PDT) Message-ID: To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 05:02:10 -0000 well. it would be good form if we could use vwrap with second life, considering the fact that many people want to use it in that way. the problem is that it's not entirely certain which delimiter should be used since the SL names database is "dirty" with respect to common delimiters. the reason the protocol includes two distinct strings in the transfer syntax is so that the transfer syntax will operate to differentiate the two names. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Apr 5, 2010 at 9:32 PM, Barry Leiba wrote: > On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick wro= te: >> no. we're proposing taking it off the table because there is a very >> high likelihood that are valid first and/or last names in a particular >> implementation that include spaces and periods. this is the reason we >> came up with having first_name and last_name as separate strings in >> the transfer syntax, and not a single string identifying the avatar's >> name. >> >> why do we need to REMOVE support for Second Life from this protocol? > > Well, here's the thing: > > First: I've spent a lot of years designing protocols, and I think it's > a terrible idea to define a specific artifact of a specific > implementation in a new protocol. =A0We've done it many times before, > and it's pretty much always caused problems. =A0Sometimes those problems > eventually worked themselves out, but I'm quite sure it was a mistake > to go there. > > Second: I don't see it as a question of "removing support for Second > Life", but one of looking at alternatives that are protocol-clean and > allow everyone to work with it. =A0And, by the way, I don't consider two > separate identifier fields, from which you're meant to pick which you > want to use, to be "protocol-clean". > > Why not define the agent identifier in a self-parsing way? =A0Something > like this should work (written in ABNF): > > =A0 agent-identifier :=3D delim 1*(id-part delim) > =A0 id-part =3D string > =A0 delim =3D 1char > > ...where the idea is that the delimiter is a single character that > appears as the first character (so it's self-identifying), and then > between ID parts. =A0The implementation would pick a character (which > could be a non-printable code point, such as 0x00 or 0x01, if > necessary) that doesn't appear in any identifier part. =A0Here's a > sampling of agent-identifiers, each within quotes just to make it > clear where they start and end: > =A0 " Joshua Linden " > =A0 ".Joshua.Linden." =A0(another way to represent the same thing) > =A0 "/Joshua/Linden/" =A0(a third) > =A0 "XJoshuaXLindenX" =A0(a fourth) > =A0 " Melanie " =A0(an identifier with just one part) > =A0 "rMelanier" =A0(the same, in another representation) > =A0 ".Melanie." =A0(or less weirdly) > =A0 " Barak Hussein Obama " =A0 (here's one with three parts) > =A0 "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit > if you're old enough to know who he is) > =A0 "~le roy~barr~" =A0(Meadhbh's example with an embedded blank) > > This scheme only adds two characters to the identifier (the leading > and trailing delimiter, and we *could* eliminate the trailing one, if > people prefer, by defining agent-identifier as "1*(delim id-part)"... > I like having it), and seems to solve everyone's problem. > > Barry, as participant > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dhc@dcrocker.net Mon Apr 5 22:03:23 2010 Return-Path: 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 8DE9F3A6862 for ; Mon, 5 Apr 2010 22:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.306 X-Spam-Level: X-Spam-Status: No, score=-5.306 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] 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 zOpLilY7hM3T for ; Mon, 5 Apr 2010 22:03:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 7E3683A685D for ; Mon, 5 Apr 2010 22:03:22 -0700 (PDT) Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o3653Bn1025762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 22:03:16 -0700 Message-ID: <4BBAC08F.8030809@dcrocker.net> Date: Mon, 05 Apr 2010 22:03:11 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: barryleiba@computer.org References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10706/Mon Apr 5 17:08:37 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 22:03:17 -0700 (PDT) Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 05:03:23 -0000 On 4/5/2010 9:32 PM, Barry Leiba wrote: > And, by the way, I don't consider two > separate identifier fields, from which you're meant to pick which you > want to use, to be "protocol-clean". Barry, you just want to take the fun out of protocol processing. Which is another way of my saying +1... > Why not define the agent identifier in a self-parsing way? Something > like this should work (written in ABNF): Within the larger system for which this protocol will operate, what participating engines need to "understand" the internal structure of the value? If it is only the creator of the value -- that is, if the protocol and other engines merely see the string as a literal token to be returned to its originator -- then it isn't parsed or internally delimited by the protocol. It's an opaque string and its originator can define parsing rules however they see fit, since they are the only ones who will in fact be seeing its internal structure. If the string is to be parsed by others, what is the purpose of the parsing? That is, what are the other engines going to do with the sub-structure to the value? The answer to this tends to guide choices about fixed vs. variable parsing rules. If this string is really going to get into the real world firstname/lastname game and is required to operate within the larger Internet, it's going to have to support dramatically more semantic complexity than just two simple strings. My impression, however, is that this is a global unique identifier, where human names are convenient choices, when they work. That leaves open the obvious problem of when they don't, since names are not globally unique. Assuming other protocol engines and participants do need to see that substructure, it's usually best to define a single, canonical syntactic structure and have all originators and parsers map to/from it for their local encodings. So the protocol defines a fixed means of delimiting internal structure, as well as a way of "quoting" the delimiter, if needed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From morgaine.dinova@googlemail.com Mon Apr 5 23:00:47 2010 Return-Path: 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 1BCFB3A68CC for ; Mon, 5 Apr 2010 23:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7-XVTSFvnwOl for ; Mon, 5 Apr 2010 23:00:45 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 2F8053A67D2 for ; Mon, 5 Apr 2010 23:00:45 -0700 (PDT) Received: by ewy24 with SMTP id 24so1493137ewy.13 for ; Mon, 05 Apr 2010 23:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=bClEXlJPiz13UQvw490fIjQ3+V9NAvIDdi0PlJ89/nY=; b=WDPqHcfMZNGMMcTxrlzxV+rFB16YPOzwql9rUM2Dp80DuKgRsDc9d2Bj8hBR+1BNOJ pF3WUIL+4cFgUv0ZHNxaaz9QUYUcaEUX1vM+7GIPP991P/pS4wuQ5I1daQHH3fn+77n6 Y7ya1oZ8fVt6VJJvDr5d8qLxLG/RD/1Mt+5aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UtNsQEFAMHFoj6YkK+yW/2ysB+yiN/VnKvi+apa5fq2iDl5nfBKMz6dDIV8zXlEqUz ltuhhLUPDU7isEPl9RIjVYrFCOPo8zZso/f5tTxi2bdKmq3vykoN+By4lJD/eY4tMf1N VcEE40n8sr11y9LjPGUY6o0mDryY+ZI/ntAUc= MIME-Version: 1.0 Received: by 10.213.105.66 with HTTP; Mon, 5 Apr 2010 23:00:38 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> Date: Tue, 6 Apr 2010 07:00:38 +0100 Received: by 10.213.65.77 with SMTP id h13mr1760285ebi.95.1270533638871; Mon, 05 Apr 2010 23:00:38 -0700 (PDT) Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00c09f8b93b138e86204838b2a6d Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 06:00:47 -0000 --00c09f8b93b138e86204838b2a6d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick wrote: > well. it would be good form if we could use vwrap with second life, > considering the fact that many people want to use it in that way. > > I'm not aware of any Linden suggesting that the single-field design would make VWRAP not usable with Second Life. Perhaps we could leave it to them to comment. > the problem is that it's not entirely certain which delimiter should > be used since the SL names database is "dirty" with respect to common > delimiters. The state of the SL names database is not the primary driving force for the design of VWRAP protocols. Morgaine. ============================= On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick wrote: > well. it would be good form if we could use vwrap with second life, > considering the fact that many people want to use it in that way. > > the problem is that it's not entirely certain which delimiter should > be used since the SL names database is "dirty" with respect to common > delimiters. > > the reason the protocol includes two distinct strings in the transfer > syntax is so that the transfer syntax will operate to differentiate > the two names. > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Apr 5, 2010 at 9:32 PM, Barry Leiba > wrote: > > On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick > wrote: > >> no. we're proposing taking it off the table because there is a very > >> high likelihood that are valid first and/or last names in a particular > >> implementation that include spaces and periods. this is the reason we > >> came up with having first_name and last_name as separate strings in > >> the transfer syntax, and not a single string identifying the avatar's > >> name. > >> > >> why do we need to REMOVE support for Second Life from this protocol? > > > > Well, here's the thing: > > > > First: I've spent a lot of years designing protocols, and I think it's > > a terrible idea to define a specific artifact of a specific > > implementation in a new protocol. We've done it many times before, > > and it's pretty much always caused problems. Sometimes those problems > > eventually worked themselves out, but I'm quite sure it was a mistake > > to go there. > > > > Second: I don't see it as a question of "removing support for Second > > Life", but one of looking at alternatives that are protocol-clean and > > allow everyone to work with it. And, by the way, I don't consider two > > separate identifier fields, from which you're meant to pick which you > > want to use, to be "protocol-clean". > > > > Why not define the agent identifier in a self-parsing way? Something > > like this should work (written in ABNF): > > > > agent-identifier := delim 1*(id-part delim) > > id-part = string > > delim = 1char > > > > ...where the idea is that the delimiter is a single character that > > appears as the first character (so it's self-identifying), and then > > between ID parts. The implementation would pick a character (which > > could be a non-printable code point, such as 0x00 or 0x01, if > > necessary) that doesn't appear in any identifier part. Here's a > > sampling of agent-identifiers, each within quotes just to make it > > clear where they start and end: > > " Joshua Linden " > > ".Joshua.Linden." (another way to represent the same thing) > > "/Joshua/Linden/" (a third) > > "XJoshuaXLindenX" (a fourth) > > " Melanie " (an identifier with just one part) > > "rMelanier" (the same, in another representation) > > ".Melanie." (or less weirdly) > > " Barak Hussein Obama " (here's one with three parts) > > "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit > > if you're old enough to know who he is) > > "~le roy~barr~" (Meadhbh's example with an embedded blank) > > > > This scheme only adds two characters to the identifier (the leading > > and trailing delimiter, and we *could* eliminate the trailing one, if > > people prefer, by defining agent-identifier as "1*(delim id-part)"... > > I like having it), and seems to solve everyone's problem. > > > > Barry, as participant > > _______________________________________________ > > 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 > --00c09f8b93b138e86204838b2a6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:=
well. it would be good form if we could use vwrap with second life,
considering the fact that many people want to use it in that way.


I'm not aware of any Linden suggesting that the s= ingle-field design would make VWRAP not usable with Second Life.=A0 Perhaps= we could leave it to them to comment.


the problem is that it's not entirely certain which delimiter should be used since the SL names database is "dirty" with respect to co= mmon
delimiters.


The state of the SL names database is not t= he primary driving force for the design of VWRAP protocols.


Morg= aine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick = <ohmeadhbh@gmai= l.com> wrote:
well. it would be good form if we could use vwrap with second life,
considering the fact that many people want to use it in that way.

the problem is that it's not entirely certain which delimiter should be used since the SL names database is "dirty" with respect to co= mmon
delimiters.

the reason the protocol includes two distinct strings in the transfer
syntax is so that the transfer syntax will operate to differentiate
the two names.

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



On Mon, Apr 5, 2010 at 9:32 PM, Bar= ry Leiba
<barryleiba.mailin= g.lists@gmail.com> wrote:
> On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
>> no. we're proposing taking it off the table because there is a= very
>> high likelihood that are valid first and/or last names in a partic= ular
>> implementation that include spaces and periods. this is the reason= we
>> came up with having first_name and last_name as separate strings i= n
>> the transfer syntax, and not a single string identifying the avata= r's
>> name.
>>
>> why do we need to REMOVE support for Second Life from this protoco= l?
>
> Well, here's the thing:
>
> First: I've spent a lot of years designing protocols, and I think = it's
> a terrible idea to define a specific artifact of a specific
> implementation in a new protocol. =A0We've done it many times befo= re,
> and it's pretty much always caused problems. =A0Sometimes those pr= oblems
> eventually worked themselves out, but I'm quite sure it was a mist= ake
> to go there.
>
> Second: I don't see it as a question of "removing support for= Second
> Life", but one of looking at alternatives that are protocol-clean= and
> allow everyone to work with it. =A0And, by the way, I don't consid= er two
> separate identifier fields, from which you're meant to pick which = you
> want to use, to be "protocol-clean".
>
> Why not define the agent identifier in a self-parsing way? =A0Somethin= g
> like this should work (written in ABNF):
>
> =A0 agent-identifier :=3D delim 1*(id-part delim)
> =A0 id-part =3D string
> =A0 delim =3D 1char
>
> ...where the idea is that the delimiter is a single character that
> appears as the first character (so it's self-identifying), and the= n
> between ID parts. =A0The implementation would pick a character (which<= br> > could be a non-printable code point, such as 0x00 or 0x01, if
> necessary) that doesn't appear in any identifier part. =A0Here'= ;s a
> sampling of agent-identifiers, each within quotes just to make it
> clear where they start and end:
> =A0 " Joshua Linden "
> =A0 ".Joshua.Linden." =A0(another way to represent the same = thing)
> =A0 "/Joshua/Linden/" =A0(a third)
> =A0 "XJoshuaXLindenX" =A0(a fourth)
> =A0 " Melanie " =A0(an identifier with just one part)
> =A0 "rMelanier" =A0(the same, in another representation)
> =A0 ".Melanie." =A0(or less weirdly)
> =A0 " Barak Hussein Obama " =A0 (here's one with three p= arts)
> =A0 "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; e= xtra credit
> if you're old enough to know who he is)
> =A0 "~le roy~barr~" =A0(Meadhbh's example with an embedd= ed blank)
>
> This scheme only adds two characters to the identifier (the leading > and trailing delimiter, and we *could* eliminate the trailing one, if<= br> > people prefer, by defining agent-identifier as "1*(delim id-part)= "...
> I like having it), and seems to solve everyone's problem.
>
> Barry, as participant
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00c09f8b93b138e86204838b2a6d-- From morgaine.dinova@googlemail.com Mon Apr 5 23:48:29 2010 Return-Path: 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 88FE03A6882 for ; Mon, 5 Apr 2010 23:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 GanpqTK8Eweh for ; Mon, 5 Apr 2010 23:48:27 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 5EA1C3A679F for ; Mon, 5 Apr 2010 23:48:27 -0700 (PDT) Received: by ewy24 with SMTP id 24so1505282ewy.13 for ; Mon, 05 Apr 2010 23:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=tO5npgESYwodrQMHslrZWsc9WFP7WhE4O/TLvsKr2XQ=; b=UWJWf2ZnZKFZdVhheWl89n8DRLu1jjVh87eCj8Wlo7xgwrrR5UBgvr46/Uxk80ns3G JN5HuNnYni2v3eEoaJCUfH163JRj7L4/Unn6b+p5/GvmuOYM+iGFyokNBL6izfkOIg1q ZJ/ZCZHHe6FaTYOSLV3aW3Tcw5kq8zt+8B1FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NtSKXQD/3ho0FYdWT6mJpND6wgbVbw4cYZc/sfx34Y/vJYvgf1ckyEIff3Lgz2DMPm 2Ly2ETSuRY+vkpcttZh8DGd2jmKtBPrGlWRURgHSF5iA/Xj/Fw1YynPL86DgCIXuMVWZ dlCAwRNwaznVr9k97OQ2EkJLk3MPLlIkEQQiQ= MIME-Version: 1.0 Received: by 10.213.105.66 with HTTP; Mon, 5 Apr 2010 23:48:22 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> Date: Tue, 6 Apr 2010 07:48:22 +0100 Received: by 10.213.39.197 with SMTP id h5mr3666588ebe.35.1270536502210; Mon, 05 Apr 2010 23:48:22 -0700 (PDT) Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00148531a8d0e3770304838bd46b Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 06:48:29 -0000 --00148531a8d0e3770304838bd46b Content-Type: text/plain; charset=ISO-8859-1 Barry, good suggestions! +1 for self-describing encodings in general; and +1 for this particular delimiter encoding, which is hard to beat for clarity, brevity, and efficiency. It should have a name! :-) Regarding the issue of the trailing delimiter, I like the Robustness Principle (although perhaps referring to RFC 760 and RFC 1122 would be more suitable here :P), so I would recommend accepting the trailing delimiter or its absence as equivalent valid terminations. For the same reason, I would also recommend accepting repeated delimiters as equivalent to single delimiters (unless you specifically want to allow null fields), otherwise delimiter characters are bound to end up in names when parsing is done poorly. :-) Morgaine. =================================== On Tue, Apr 6, 2010 at 5:32 AM, Barry Leiba < barryleiba.mailing.lists@gmail.com> wrote: > On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick > wrote: > > no. we're proposing taking it off the table because there is a very > > high likelihood that are valid first and/or last names in a particular > > implementation that include spaces and periods. this is the reason we > > came up with having first_name and last_name as separate strings in > > the transfer syntax, and not a single string identifying the avatar's > > name. > > > > why do we need to REMOVE support for Second Life from this protocol? > > Well, here's the thing: > > First: I've spent a lot of years designing protocols, and I think it's > a terrible idea to define a specific artifact of a specific > implementation in a new protocol. We've done it many times before, > and it's pretty much always caused problems. Sometimes those problems > eventually worked themselves out, but I'm quite sure it was a mistake > to go there. > > Second: I don't see it as a question of "removing support for Second > Life", but one of looking at alternatives that are protocol-clean and > allow everyone to work with it. And, by the way, I don't consider two > separate identifier fields, from which you're meant to pick which you > want to use, to be "protocol-clean". > > Why not define the agent identifier in a self-parsing way? Something > like this should work (written in ABNF): > > agent-identifier := delim 1*(id-part delim) > id-part = string > delim = 1char > > ...where the idea is that the delimiter is a single character that > appears as the first character (so it's self-identifying), and then > between ID parts. The implementation would pick a character (which > could be a non-printable code point, such as 0x00 or 0x01, if > necessary) that doesn't appear in any identifier part. Here's a > sampling of agent-identifiers, each within quotes just to make it > clear where they start and end: > " Joshua Linden " > ".Joshua.Linden." (another way to represent the same thing) > "/Joshua/Linden/" (a third) > "XJoshuaXLindenX" (a fourth) > " Melanie " (an identifier with just one part) > "rMelanier" (the same, in another representation) > ".Melanie." (or less weirdly) > " Barak Hussein Obama " (here's one with three parts) > "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit > if you're old enough to know who he is) > "~le roy~barr~" (Meadhbh's example with an embedded blank) > > This scheme only adds two characters to the identifier (the leading > and trailing delimiter, and we *could* eliminate the trailing one, if > people prefer, by defining agent-identifier as "1*(delim id-part)"... > I like having it), and seems to solve everyone's problem. > > Barry, as participant > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00148531a8d0e3770304838bd46b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry, good suggestions!

+1 for self-describing encodings in general= ;=A0 and

+1 for this particular delimiter encoding, which is hard to= beat for clarity, brevity, and efficiency.=A0 It should have a name! :-)

Regarding the issue of the trailing delimiter, I like the Robustness Principle= (although perhaps referring to RFC 760 and RFC 1122 would be more suit= able here :P), so I would recommend accepting the trailing delimiter or its= absence as equivalent valid terminations.=A0 For the same reason, I would = also recommend accepting repeated delimiters as equivalent to single delimi= ters (unless you specifically want to allow null fields), otherwise delimit= er characters are bound to end up in names when parsing is done poorly. :-)=


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Tue, Apr 6, 2010 at 5:32 AM, Barry Leiba= <barryleiba.mailing.lists@gmail.com> wrote:
On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
> no. we're proposing taking it off the table because there is a ver= y
> high likelihood that are valid first and/or last names in a particular=
> implementation that include spaces and periods. this is the reason we<= br> > came up with having first_name and last_name as separate strings in > the transfer syntax, and not a single string identifying the avatar= 9;s
> name.
>
> why do we need to REMOVE support for Second Life from this protocol?
Well, here's the thing:

First: I've spent a lot of years designing protocols, and I think it= 9;s
a terrible idea to define a specific artifact of a specific
implementation in a new protocol. =A0We've done it many times before, and it's pretty much always caused problems. =A0Sometimes those problem= s
eventually worked themselves out, but I'm quite sure it was a mistake to go there.

Second: I don't see it as a question of "removing support for Seco= nd
Life", but one of looking at alternatives that are protocol-clean and<= br> allow everyone to work with it. =A0And, by the way, I don't consider tw= o
separate identifier fields, from which you're meant to pick which you want to use, to be "protocol-clean".

Why not define the agent identifier in a self-parsing way? =A0Something
like this should work (written in ABNF):

=A0 agent-identifier :=3D delim 1*(id-part delim)
=A0 id-part =3D string
=A0 delim =3D 1char

...where the idea is that the delimiter is a single character that
appears as the first character (so it's self-identifying), and then
between ID parts. =A0The implementation would pick a character (which
could be a non-printable code point, such as 0x00 or 0x01, if
necessary) that doesn't appear in any identifier part. =A0Here's a<= br> sampling of agent-identifiers, each within quotes just to make it
clear where they start and end:
=A0 " Joshua Linden "
=A0 ".Joshua.Linden." =A0(another way to represent the same thin= g)
=A0 "/Joshua/Linden/" =A0(a third)
=A0 "XJoshuaXLindenX" =A0(a fourth)
=A0 " Melanie " =A0(an identifier with just one part)
=A0 "rMelanier" =A0(the same, in another representation)
=A0 ".Melanie." =A0(or less weirdly)
=A0 " Barak Hussein Obama " =A0 (here's one with three parts= )
=A0 "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra= credit
if you're old enough to know who he is)
=A0 "~le roy~barr~" =A0(Meadhbh's example with an embedded b= lank)

This scheme only adds two characters to the identifier (the leading
and trailing delimiter, and we *could* eliminate the trailing one, if
people prefer, by defining agent-identifier as "1*(delim id-part)"= ;...
I like having it), and seems to solve everyone's problem.

Barry, as participant
_________________________________________= ______
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00148531a8d0e3770304838bd46b-- From cs@comlounge.net Tue Apr 6 02:08:29 2010 Return-Path: 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 8C3F93A6A6F for ; Tue, 6 Apr 2010 02:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_36=0.6] 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 M8rGGNdrV5Om for ; Tue, 6 Apr 2010 02:08:28 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 12B913A683C for ; Tue, 6 Apr 2010 02:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 27C681CE0394 for ; Tue, 6 Apr 2010 11:08:24 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTq8jPdFWDgy for ; Tue, 6 Apr 2010 11:08:23 +0200 (CEST) Received: from [192.168.178.100] (p5B393A70.dip.t-dialin.net [91.57.58.112]) by post.comlounge.net (Postfix) with ESMTPSA id 7D7611CE038E for ; Tue, 6 Apr 2010 11:08:23 +0200 (CEST) Message-ID: <4BBAFA0A.7050308@comlounge.net> Date: Tue, 06 Apr 2010 11:08:26 +0200 From: Christian Scholz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: vwrap@ietf.org References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 09:08:29 -0000 Hi! Am 05.04.10 20:39, schrieb Hurliman, John: > At the IETF77 meeting there was talk about removing the first name / last name assumptions from the avatar identifier, but it looks like that conversation didn't carry over to the mailing list. Does anyone know exactly which I-Ds (and which sections) reference avatar identifiers as first_name+last_name? I still don't really understand why you aren't levering existing specification like OpenSocial/PortableContacts: http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Person http://portablecontacts.net/draft-spec.html Shouldn't they have already most of the things defined and you would gain additional interoperability by using it? -- Christian -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de) new podcast: Data Without Borders (http://datawithoutborders.net) From carlo@alinoe.com Tue Apr 6 05:03:25 2010 Return-Path: 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 3CC863A6837 for ; Tue, 6 Apr 2010 05:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.17 X-Spam-Level: * X-Spam-Status: No, score=1.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 VudaMCAWpR-F for ; Tue, 6 Apr 2010 05:03:24 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 52E873A688A for ; Tue, 6 Apr 2010 05:03:18 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406120314.QOBN20186.viefep20-int.chello.at@edge05.upcmail.net>; Tue, 6 Apr 2010 14:03:14 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id 2C3B1e01L0FlQed05C3C6B; Tue, 06 Apr 2010 14:03:14 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz7Ut-00076n-2u; Tue, 06 Apr 2010 14:03:11 +0200 Date: Tue, 6 Apr 2010 14:03:11 +0200 From: Carlo Wood To: Mark Lentczner Message-ID: <20100406120311.GA27189@alinoe.com> References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=KBHyIoyMIRH440NzHl6uMYpbxJngTLC2P1JzLC/QbPg= c=1 sm=0 a=yuyHaSdb0uMA:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=iXggwkVfAAAA:8 a=cfHPFXhNAAAA:8 a=48vgC7mUAAAA:8 a=BjFOTwK7AAAA:8 a=j5TiJ3MzATQWh9SFVb4A:9 a=lBxYxALo3QCaRjP7E8VsFTtytSIA:4 a=CjuIK1q_8ugA:10 a=x6U5xrJgyBEA:10 a=IYwbpFaHkegA:10 a=lZB815dzVvQA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:03:25 -0000 Yet another place where protocol negotiation would come in handy. If I had more time, I'd write a draft for the protocol negotiation that I have in mind :/ On Wed, Mar 31, 2010 at 04:27:48PM -0700, Mark Lentczner wrote: > In trying to think thought the scenarios where a version field might be workable, I'm coming up short: > > A v.n only reader encountering v.n+1 could only make two choices: Ignore everything it doesn't understand and assume that the semantics of the content aren't affected, or reject the transmission entirely. We'd have to choose now how it should react. > > If it is ignoring things, then it seems that any v.n+1 extension would have to be defined like "If you understand v.n+1, then ignore some (or all) of the v.n stuff and substitute this richer data." But at that point, we are mostly using this version stuff as a way of stuffing two or more versions of the data in the same container. Extending this beyond one or two revisions is likely to get out of hand. > > If it is rejecting things, then this has little use here, since there must be some signaling and protocol for negotiation to handle this case in some outer scope (HTTP, say). But then, why not just embed the version information at the higher scope (MIME-type, say)? > > The "ignore by preserve" semantic works well for processing streams, and in cases where the vast bulk of the data is understood, and the ignored, foreign markup, isn't semantically important. VWRAP's use of LLSD doesn't seem to fit that model. > > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Carlo Wood From carlo@alinoe.com Tue Apr 6 05:12:38 2010 Return-Path: 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 B66903A6900 for ; Tue, 6 Apr 2010 05:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 tCUSKL3QH3w3 for ; Tue, 6 Apr 2010 05:12:38 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 9A9283A68F0 for ; Tue, 6 Apr 2010 05:12:37 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406121234.CRS2376.viefep14-int.chello.at@edge01.upcmail.net>; Tue, 6 Apr 2010 14:12:34 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id 2CCV1e00B0FlQed01CCXb7; Tue, 06 Apr 2010 14:12:34 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz7ds-0007Bt-AQ; Tue, 06 Apr 2010 14:12:28 +0200 Date: Tue, 6 Apr 2010 14:12:28 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20100406121228.GB27189@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <32F75F62-9787-4453-B0FE-561B312336E2@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=tsaDvxd5BMYuajhtvJLL+Ppe47iaIgCGP4JcOtoQkcg= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=bMaSZRU4k9mw74947FwA:9 a=aNEpk-Sp9PZ5zNX7k5btjcLp3JoA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:12:38 -0000 On Mon, Apr 05, 2010 at 01:25:19PM -0700, Meadhbh Hamrick wrote: > if we wanted to construct an entity identifier by concatenating the > first name, a separator and a last name, we would have to find a > separator that was not currently in use. Yup, a space thus. "Firstname Lastname" -- Carlo Wood From carlo@alinoe.com Tue Apr 6 05:19:14 2010 Return-Path: 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 74D0F3A688A for ; Tue, 6 Apr 2010 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 OzDqIGGOJpKX for ; Tue, 6 Apr 2010 05:19:13 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id DA8B23A6837 for ; Tue, 6 Apr 2010 05:19:12 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406121907.WQA10355.viefep19-int.chello.at@edge01.upcmail.net>; Tue, 6 Apr 2010 14:19:07 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id 2CK31e02b0FlQed01CK4v9; Tue, 06 Apr 2010 14:19:07 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz7kE-0007FD-9v; Tue, 06 Apr 2010 14:19:02 +0200 Date: Tue, 6 Apr 2010 14:19:02 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20100406121902.GC27189@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=EFR1pENkxzhdjTnRVAuI+iHrp5zsYr2ENPL4njVhkqM= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=cfHPFXhNAAAA:8 a=BjFOTwK7AAAA:8 a=O1SwaGOP60LJ86N2FHwA:9 a=CSM-pXZHCyfDh65i7TsA:7 a=Th-L3fkGE03G7omjh_ltPnw2spkA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=zmEQBIeP_Nde0kdJ:21 a=vU-g2LIvodFiN1Nm:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:19:15 -0000 On Mon, Apr 05, 2010 at 01:07:15PM -0700, Meadhbh Hamrick wrote: > why do we need to REMOVE support for Second Life from this protocol? Second Life would remove itself imho. The point is that the "agent login ID" can be anything, should be allowed to be anything. Surely Linden Lab can come up with a way to put their login stuff in a single string? That is NOT too difficult at ALL. You will have to write loads of new code to support VWRAP. It will probably be a very special and new vwrap.cpp file. So, just implement that this new code will understand "Firstname Lastname" as a single (input) string and have it output two strings "Firstname" and "Lastname" and off you go. What is proposed so far is to encode it as "Firstname Lastname" (just catenate the two, as is done on for example https://jira.secondlife.com/cas/login Can you explain why the login interface of the jira has no problems with this, but Linden Lab claims it will be forced out of VWRAP? -- Carlo Wood From carlo@alinoe.com Tue Apr 6 05:33:13 2010 Return-Path: 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 A1B323A6837 for ; Tue, 6 Apr 2010 05:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_43=0.6] 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 cEiccCO3E+ol for ; Tue, 6 Apr 2010 05:33:12 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 28B293A6810 for ; Tue, 6 Apr 2010 05:33:11 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406123309.KRC26047.viefep20-int.chello.at@edge01.upcmail.net>; Tue, 6 Apr 2010 14:33:09 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id 2CZ51e0410FlQed01CZ6ia; Tue, 06 Apr 2010 14:33:09 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz7xp-0007S0-Di; Tue, 06 Apr 2010 14:33:05 +0200 Date: Tue, 6 Apr 2010 14:33:05 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20100406123305.GD27189@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=KBHyIoyMIRH440NzHl6uMYpbxJngTLC2P1JzLC/QbPg= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=o8aY3WBxWsZXkbQwgDcA:9 a=X_Of6uW9cDryZY7z61oA:7 a=ORx7SrKydGfGl4we1NGS_N2xmnkA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:33:13 -0000 On Mon, Apr 05, 2010 at 01:41:28PM -0700, Meadhbh Hamrick wrote: > we have two existing implementations from organizations who have > stated they would like to use this protocol. both use two strings at > the moment. both COULD be converted to use a single identifier, and > probably should, but one of them has the problem that the data is not > "clean" and it would be difficult to find a programmatic mechanism to > convert two strings to a single string without ambiguity. I don't believe this. Does Second Life have *ANY* login name that has a space in it's LAST name? If so, please tell me which and allow me to find it in the People Search in world. If not, then your problem is solved: search for the first space from the back, that is your separator. Here is the implementation, let me know if you need a special license or a transfer of copyright. #include #include int main(int argc, char* argv[]) { if (argc != 2) { printf("Usage: %s agent-ID-string\n", argv[0]); return; } char* space = strrchr(argv[1], ' '); if (!space) { printf("This is not a valid Second Life name\n"); return; } /* Start of EXTRA code LL needs to add to support VWRAP */ size_t len = space - argv[1]; char* firstname = argv[1]; argv[1][len] = 0; char* lastname = firstname + len + 1; /* End of EXTRA code LL needs to add to support VWRAP */ printf("Firstname = \"%s\", lastname = \"%s\"\n", firstname, lastname); } Example output: $ ./a.out "abcde,fghi.jkl Linden" Firstname = "abcde,fghi.jkl", lastname = "Linden" -- Carlo Wood From carlo@alinoe.com Tue Apr 6 06:01:48 2010 Return-Path: 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 B1B233A6903 for ; Tue, 6 Apr 2010 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 qkdclghClVB5 for ; Tue, 6 Apr 2010 06:01:48 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1AC0E3A68F7 for ; Tue, 6 Apr 2010 06:01:46 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406130143.PTB14297.viefep15-int.chello.at@edge02.upcmail.net>; Tue, 6 Apr 2010 15:01:43 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id 2D1g1e04N0FlQed02D1jHD; Tue, 06 Apr 2010 15:01:43 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz8PT-0007iq-DE; Tue, 06 Apr 2010 15:01:39 +0200 Date: Tue, 6 Apr 2010 15:01:39 +0200 From: Carlo Wood To: barryleiba@computer.org Message-ID: <20100406130139.GE27189@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=O+FWVpunvrlG1gSnSO6WiIQ7o0MJ4laHqrEcUJ8XjIg= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=7rn-j1GDkeTFXmSRjigA:9 a=qPRGy5-s6wMnM6WDVqoA:7 a=yqjqnoyER0KNn7z3c_aClYezI-wA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=p0Pubx7qlqYOj58O:21 a=VYJuvW5YlQ32K-Nw:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:01:48 -0000 On Tue, Apr 06, 2010 at 12:32:08AM -0400, Barry Leiba wrote: > This scheme only adds two characters to the identifier (the leading > and trailing delimiter, and we *could* eliminate the trailing one, if > people prefer, by defining agent-identifier as "1*(delim id-part)"... > I like having it), and seems to solve everyone's problem. It solves Linden Labs "problem". I mean, you are not suggesting that this should be part of VWRAP right? VWRAP doesn't need to specify how each login server will decode the AgentID string. That can be different from provider to provider. Since Meadhbh kept saying that the LL database is "dirty" so that not ANY single delimiter will do (they have first and last names that contain any of the 256 binary values of character), how about encoding it like this: [length][firstname][lastname] where [length] is the first byte (8 bit) and represents the length of the firstname. For example: "\05CarloWood" That would allow for ANY characters anywhere in both first- and lastname. Implementation example (in C++): #include int const maxnamelen = 32; // Must be less than 256. int main() { std::string const input_firstname = "Carlo"; std::string const input_lastname = "Wood"; // Encode LL name pair to agentID for VWRAP. std::string agentID; agentID = (unsigned char)input_firstname.length(); // Never 0. agentID += input_firstname; agentID += input_lastname; // Decode VWRAP agentID to LL name pair. size_t firstlen = agentID[0]; std::string firstname = agentID.substr(1, firstlen); std::string lastname = agentID.substr(firstlen + 1, agentID.length() - 1 - firstlen); std::cout << "Firstname = \"" << firstname << "\"; lastname = \"" << lastname << "\"." << std::endl; } -- Carlo Wood From carlo@alinoe.com Tue Apr 6 06:07:54 2010 Return-Path: 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 7AF323A68AA for ; Tue, 6 Apr 2010 06:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_36=0.6] 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 AVjnM4Hn54Xo for ; Tue, 6 Apr 2010 06:07:51 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 33D2A3A6897 for ; Tue, 6 Apr 2010 06:07:51 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep18-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406130748.BIWU22010.viefep18-int.chello.at@edge03.upcmail.net>; Tue, 6 Apr 2010 15:07:48 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id 2D7j1e0850FlQed03D7l2Z; Tue, 06 Apr 2010 15:07:48 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1Nz8VL-0007lj-1j; Tue, 06 Apr 2010 15:07:43 +0200 Date: Tue, 6 Apr 2010 15:07:43 +0200 From: Carlo Wood To: Christian Scholz Message-ID: <20100406130743.GF27189@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <4BBAFA0A.7050308@comlounge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBAFA0A.7050308@comlounge.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=kR1739jI04gsLPPBAx/k25XPeS1fzQof9TaPDYrpM2k= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=b01i9L7eAAAA:8 a=yk1MOivEAAAA:8 a=2MbQap6QAAAA:8 a=Ziag63ztAAAA:8 a=3pvf0x5xAAAA:8 a=LXddmZc4AAAA:8 a=se303djyAAAA:8 a=48vgC7mUAAAA:8 a=BjFOTwK7AAAA:8 a=8JQorLMKLdRwVXz0nswA:9 a=x1278ulWokOlIgbWPHgA:7 a=BYoYXMqqSBWtl7C9E-qmLKq6N3MA:4 a=CjuIK1q_8ugA:10 a=Ex2uEIveQcsA:10 a=3gi9D5O4QywA:10 a=dVYeGoOdMukA:10 a=lZB815dzVvQA:10 a=bW3kdApBr58A:10 a=NT0wKs-cDrnHh0FC:21 a=2updkLhUaop-OTB6:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:07:54 -0000 I don't think that adding ALSO the religion, sexual orientation, names of children and job interests to the VWRAP specs will solve much. Note we are talking about the agentID - not the complete blue print of someone private Real Life data. EVEN if some agent login provider wanted to put lot of (private) data in the agentID string, then that is his problem (like it is Linden Lab's "problem" to catenate their first/last name fields and later decode those again) and how to do that has no place in VWRAP imho. On Tue, Apr 06, 2010 at 11:08:26AM +0200, Christian Scholz wrote: > Hi! > > Am 05.04.10 20:39, schrieb Hurliman, John: > > At the IETF77 meeting there was talk about removing the first name / last name assumptions from the avatar identifier, but it looks like that conversation didn't carry over to the mailing list. Does anyone know exactly which I-Ds (and which sections) reference avatar identifiers as first_name+last_name? > > I still don't really understand why you aren't levering existing > specification like OpenSocial/PortableContacts: > > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Person > http://portablecontacts.net/draft-spec.html > > Shouldn't they have already most of the things defined and you would > gain additional interoperability by using it? > > -- Christian > > -- > Christian Scholz Homepage: http://comlounge.net > COM.lounge GmbH blog: http://mrtopf.de/blog > Hanbrucher Str. 33 Skype: HerrTopf > 52064 Aachen Video Blog: http://comlounge.tv > Tel: +49 241 400 730 0 E-Mail cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T > > neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de) > new podcast: Data Without Borders (http://datawithoutborders.net) > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Carlo Wood From ohmeadhbh@gmail.com Tue Apr 6 07:14:40 2010 Return-Path: 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 00AEB3A67F4 for ; Tue, 6 Apr 2010 07:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] 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 x8FjTCXP3epA for ; Tue, 6 Apr 2010 07:14:38 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 83C543A67E3 for ; Tue, 6 Apr 2010 07:14:38 -0700 (PDT) Received: by qyk11 with SMTP id 11so5070247qyk.13 for ; Tue, 06 Apr 2010 07:14:33 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=S/u/TzuNUbq2r14vJYp6BMHpsDKE1RtOjYyg973qJDA=; b=qsB5ReF4M6nXIatEcY4n4NUYTkgstK3ZNJjXqS6SU2KcKD08KgIVLa0ovrSs64GbZF aDVCioJHWre2cki3oK1VF4TU09ip6nbJA6bLkgO9s69MbqfXtqLnsdT3iZ/Rz8xTdtb1 LP8xlB3pj6I9Anu8Sd9HRROEXH/0h3Ef88A/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=n8VD7I9HbkeQXCko37D/+r7iMPEf5f6NcVL1jI4jeNE7srjQUh1tCePeq41DZnTz0L 85AIbBl4ADU662FpLcY3gBHBiHT7Fz/KdnyzQLw02MdbJkaW8SkYx+vGTX6HxNlHTEJu yBFaXN4Iyik3sOAhi3nuqJMphEU04QBx/78Us= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 07:14:13 -0700 (PDT) In-Reply-To: <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 07:14:13 -0700 Received: by 10.229.224.79 with SMTP id in15mr12001083qcb.76.1270563273310; Tue, 06 Apr 2010 07:14:33 -0700 (PDT) Message-ID: To: Mark Lentczner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:14:40 -0000 what do systems that only understand xml 1.0 do if they encounter xml 1.1? the purpose of the version tag and the rule that you ignore but preserve tags you don't understand is to provide the hope for extension for situations we do not currently foresee. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Wed, Mar 31, 2010 at 4:27 PM, Mark Lentczner wrote= : > In trying to think thought the scenarios where a version field might be w= orkable, I'm coming up short: > > A v.n only reader encountering v.n+1 could only make two choices: Ignore = everything it doesn't understand and assume that the semantics of the conte= nt aren't affected, or reject the transmission entirely. We'd have to choos= e now how it should react. > > If it is ignoring things, then it seems that any v.n+1 extension would ha= ve to be defined like "If you understand v.n+1, then ignore some (or all) o= f the v.n stuff and substitute this richer data." But at that point, we are= mostly using this version stuff as a way of stuffing two or more versions = of the data in the same container. Extending this beyond one or two revisio= ns is likely to get out of hand. > > If it is rejecting things, then this has little use here, since there mus= t be some signaling and protocol for negotiation to handle this case in som= e outer scope (HTTP, say). But then, why not just embed the version informa= tion at the higher scope (MIME-type, say)? > > The "ignore by preserve" semantic works well for processing streams, and = in cases where the vast bulk of the data is understood, and the ignored, fo= reign markup, isn't semantically important. VWRAP's use of LLSD doesn't see= m to fit that model. > > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Tue Apr 6 07:18:07 2010 Return-Path: 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 1CA343A67F4 for ; Tue, 6 Apr 2010 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FIwUXG5iPyAK for ; Tue, 6 Apr 2010 07:18:05 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 88D563A696B for ; Tue, 6 Apr 2010 07:18:04 -0700 (PDT) Received: by pwj2 with SMTP id 2so2493077pwj.31 for ; Tue, 06 Apr 2010 07:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ZG9mYbX43uz0X1Cf8YUEun//9+/27NRHZ9MBxIQh6UY=; b=eCvcKiIajrz8zxLIzpLjWCoZElAxuVu4+0QsILX20ga6yB51WVe4im2bAY6w5dWOIE JLntl/DX/zXJMrwISgCnoPyegAzUuRxy0Q24tPfPyXfD8PVvO1oHtAhnEI8R70j4gYWj PhbELT3D9mhSPSAhX323SehmjDjgFuvBZdL1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FF2LzeK9tSjSYlPSJUoGQJeJOOVsVzUiB2mLQcY2moLo0Vze894f/XuyQjBeDyS7N1 sNHIoud2fPBY3l+ENBzrhp6uQHxJ5gYm6UG264I7x9WSmLVn2E5Z3na/nMS9iXqh2jbj 8Fdd9d2OjcLpJEDICWUtVZq8+6guWdZR+uDaE= Received: by 10.114.5.12 with SMTP id 12mr6415934wae.64.1270563479602; Tue, 06 Apr 2010 07:17:59 -0700 (PDT) Received: from [192.168.0.50] (adsl-69-105-85-58.dsl.scrm01.pacbell.net [69.105.85.58]) by mx.google.com with ESMTPS id 23sm7755534qyk.11.2010.04.06.07.17.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 07:17:58 -0700 (PDT) Message-ID: <4BBB45FA.8050408@gmail.com> Date: Tue, 06 Apr 2010 07:32:26 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: vwrap@ietf.org References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: barryleiba@computer.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:18:07 -0000 Barry Leiba wrote: > Here's a > sampling of agent-identifiers, each within quotes just to make it > clear where they start and end: > " Joshua Linden " > ".Joshua.Linden." (another way to represent the same thing) > "/Joshua/Linden/" (a third) > "XJoshuaXLindenX" (a fourth) > " Melanie " (an identifier with just one part) > "rMelanier" (the same, in another representation) > ".Melanie." (or less weirdly) > " Barak Hussein Obama " (here's one with three parts) > "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit > if you're old enough to know who he is) > "~le roy~barr~" (Meadhbh's example with an embedded blank) > > Another suggestion, if one used XML like tags: Barak Hussein Obama Then the string can be escaped into the name field. For those that don't want first/last, they just skip the tags. For those that only want first/last, they pull the text only within with first/last tags. From ohmeadhbh@gmail.com Tue Apr 6 07:20:31 2010 Return-Path: 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 836B43A6860 for ; Tue, 6 Apr 2010 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 mSX4Thwd6Q6J for ; Tue, 6 Apr 2010 07:20:21 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 407BE3A67E7 for ; Tue, 6 Apr 2010 07:20:21 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1662376qwb.31 for ; Tue, 06 Apr 2010 07:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=SBK6TX6o0PWYLR6RCi+NLJEHPDoSEaCSX0wXPVygkJA=; b=E9Np+TaIaa/l9p9ZmOHk75nKvSG3I3rRjo88KTmSv4tfgC5F8EcehON0ytkag+Iaxx hVPwt+wtbCwLl4A8CgBsqJytfu74Iw/9Qb4zkobHK1dC+5RagDVnoIJ1uM2L2h8ogs77 IheGWCINOPinTIxZ7VCu2Us8BXyaOj6LTcbNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Lmd7wUh4DicfPOnyR+SOFQelcAS5UMwBByZ88J2QspWH5qSnOQx8ZsfPidj7kkHl/g +YX0s8/XJC8Dyit0zF7GM7Ce/ZNuAcQdzWECvhNsWkQ91fIqb02Ck4TeDTxgRzGb8YO+ SNa8dOQdm5S19r6GQlKUdOtYJFLqFR5JVlHjQ= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 07:19:56 -0700 (PDT) From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 07:19:56 -0700 Received: by 10.229.99.77 with SMTP id t13mr11874119qcn.80.1270563616431; Tue, 06 Apr 2010 07:20:16 -0700 (PDT) Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:20:31 -0000 okay. if we're going to remove VWRAP from all current implementations, i vote we remove MD5 from the auth spec and replace it with a MIC with better security properties, like SHA224 or SHA256. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From ohmeadhbh@gmail.com Tue Apr 6 07:23:25 2010 Return-Path: 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 198013A68AC for ; Tue, 6 Apr 2010 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_50=0.001, J_CHICKENPOX_36=0.6] 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 CWUcbbcYgAiR for ; Tue, 6 Apr 2010 07:23:23 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 56EC83A68B3 for ; Tue, 6 Apr 2010 07:23:20 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1663444qwb.31 for ; Tue, 06 Apr 2010 07:23:18 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=XeoZfOqpBQanQwN5IRN0QaDAm0d5oeEmEIeUiYKd4/8=; b=smMd1cZhxLTyk2C6dXF0IIBoexoPY2PvkVTM273i62H7312tB0oTC93LMOEBsxxi9V eOEnDaWoFos4FW7G4999Ss+AE9SM/cjEaMgNXm+/xA3lbb6leuapqAnBRuLmtvKNM1vo bvI4wSMnJLl1lgJSgfWTf88Di/WcM10eq/nrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=t3+BcXZcR/7gtvCCfJejz98f99Fz+nzj2BXUh9USdyYRHYBi945TVdd7vICkyT3ri8 51F+aG1lXPCrT+EM94LO2dhuQXs5udz3WHiyizitovXDI45kLpjPxF9v3VsvPc86sm9s CL1uFxaLKVIPVcRZHlzaiwDoG+rsNnjOScg1Q= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 07:17:27 -0700 (PDT) In-Reply-To: <4BBAFA0A.7050308@comlounge.net> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <4BBAFA0A.7050308@comlounge.net> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 07:17:27 -0700 Received: by 10.229.190.133 with SMTP id di5mr4177947qcb.23.1270563467148; Tue, 06 Apr 2010 07:17:47 -0700 (PDT) Message-ID: To: Christian Scholz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:23:25 -0000 because we are building a normative standard and we need to reference existing standards from recognized SDOs, not draft documents without copyright notices whose IPR status is unknown. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 2:08 AM, Christian Scholz wrote: > Hi! > > Am 05.04.10 20:39, schrieb Hurliman, John: >> At the IETF77 meeting there was talk about removing the first name / las= t name assumptions from the avatar identifier, but it looks like that conve= rsation didn't carry over to the mailing list. Does anyone know exactly whi= ch I-Ds (and which sections) reference avatar identifiers as first_name+las= t_name? > > I still don't really understand why you aren't levering existing > specification like OpenSocial/PortableContacts: > > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#P= erson > http://portablecontacts.net/draft-spec.html > > Shouldn't they have already most of the things defined and you would > gain additional interoperability by using it? > > -- Christian > > -- > Christian Scholz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Homep= age: http://comlounge.net > COM.lounge GmbH =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0blog: http://mrtopf.de/blog > Hanbrucher Str. 33 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Skype: HerrTopf > 52064 Aachen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vide= o Blog: http://comlounge.tv > Tel: +49 241 400 730 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 E-Mail cs@comlounge.net > Fax: +49 241 979 00 850 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 IRC: MrTopf, Tao_T > > neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de) > new podcast: Data Without Borders (http://datawithoutborders.net) > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Tue Apr 6 07:28:35 2010 Return-Path: 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 6FC753A67E3 for ; Tue, 6 Apr 2010 07:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 aS+WXbLmjJ+a for ; Tue, 6 Apr 2010 07:28:34 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 4F2C23A67B4 for ; Tue, 6 Apr 2010 07:28:31 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1665405qwb.31 for ; Tue, 06 Apr 2010 07:28:28 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=4aZAAfR5yF5cmwo+PxOGOoe7d8Y9vmZOd+HS/JFGCSs=; b=JwrLoid1SVmyOEvxW0pvJhLXZuzJT6IlmG85STFa+Rvof31s7EnGLNTDPLNmY/tUZr FYGIpE0cRlizMuoPda2OT0eaf6v0XjTziblAjNEyFZ1J/4JqHdphxgRjYvZzC0mVAJ8p ByJTl8fYcvqtnx/silCv9xba1V3FFEWiANtEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lPRWYKreQP3CV+bdqtoYPySVcgTqtQRbtOobI8AyL7my4gc44oUBAbgTloSEv/hg+S A1TF69FxrhSqtfP0WkX/bMmAPxgBTsYjkqZ9YjwdTU/ujV6u17w56c8QQJU98GXZvaVz 8AKSpnu2KLPq2VLnsV4Sv0tLEIVsshdl5VZQY= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 07:28:08 -0700 (PDT) In-Reply-To: <4BBB45FA.8050408@gmail.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 07:28:08 -0700 Received: by 10.229.190.133 with SMTP id di5mr4194591qcb.23.1270564108410; Tue, 06 Apr 2010 07:28:28 -0700 (PDT) Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org, barryleiba@computer.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:28:35 -0000 not sure what you're going for here... the example is not valid XML, but i think your recommendation is simply to use XML-like tags in the string that gets put inside the transfer encoding, so if you encoded it with JSON it would be something like: { "name": "simonle bon"} or with XML, it would be encoded as: name <first>simon</first><last>le bon</last> ? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 7:32 AM, Dzonatas Sol wrote: > Barry Leiba wrote: >> >> =A0Here's a >> sampling of agent-identifiers, each within quotes just to make it >> clear where they start and end: >> =A0 " Joshua Linden " >> =A0 ".Joshua.Linden." =A0(another way to represent the same thing) >> =A0 "/Joshua/Linden/" =A0(a third) >> =A0 "XJoshuaXLindenX" =A0(a fourth) >> =A0 " Melanie " =A0(an identifier with just one part) >> =A0 "rMelanier" =A0(the same, in another representation) >> =A0 ".Melanie." =A0(or less weirdly) >> =A0 " Barak Hussein Obama " =A0 (here's one with three parts) >> =A0 "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit >> if you're old enough to know who he is) >> =A0 "~le roy~barr~" =A0(Meadhbh's example with an embedded blank) >> >> > > Another suggestion, if one used XML like tags: > > Barak Hussein Obama > > Then the string can be escaped into the name field. For those that don't > want first/last, they just skip the tags. For those that only want > first/last, they pull the text only within with first/last tags. > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Tue Apr 6 07:57:50 2010 Return-Path: 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 98CDC3A6978 for ; Tue, 6 Apr 2010 07:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 K7s-puFWNNkm for ; Tue, 6 Apr 2010 07:57:49 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 40EDF3A6966 for ; Tue, 6 Apr 2010 07:57:49 -0700 (PDT) Received: by qyk11 with SMTP id 11so5116417qyk.13 for ; Tue, 06 Apr 2010 07:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yay4NdPgkj3GaM0cBWs4imkVA+keF83P5Zb2aFfKiE8=; b=ikKsb40lUokJZJNtyLQXkU9KLxmXZXhLGnBWXzoSuqvmnez9tTgJvATG40rgW1bY5h DdhTHa9HQxYIYlTdXF09JTlZCY5Up7OVsxrk1ggRrg4zHOrxCmKnbJ5RKYma49be86AN b8ZDrGpkyzQGb8gnJWUpsBEgHcLMPHvr2jMDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GwluEL+4W75ZAThoMaDFabrl5QA0lI85kkoVnyCIl+Aue3TlnJMxNW87ngqiqmi/zc 0JmXJx91Igqb/VFctklLS6MZdTOlPQF9lGzwevTrqTGCT41MdL3e3RuxrdUY54tFAvfc 3vIYdd/1WjHPw0VtI2zQvnY5gX2jWakExsygY= Received: by 10.224.17.232 with SMTP id t40mr2677700qaa.47.1270565387663; Tue, 06 Apr 2010 07:49:47 -0700 (PDT) Received: from [192.168.0.50] (adsl-69-105-85-58.dsl.scrm01.pacbell.net [69.105.85.58]) by mx.google.com with ESMTPS id 8sm15373598qwj.10.2010.04.06.07.49.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 07:49:46 -0700 (PDT) Message-ID: <4BBB4D6E.60600@gmail.com> Date: Tue, 06 Apr 2010 08:04:14 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: Meadhbh Hamrick References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org, barryleiba@computer.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:57:50 -0000 It's a valid XML snipplet, I just didn't include the full wrap of LLSD or JSON as you have. You still need to keep the space between the tags, or else: "simonle bon" Would look like this without tags: "simonle bon" Which is not desired, so it would need to be: "simon le bon" Where there is a space between "" and "" tags. Better example, if someone simply dropped the tags on this input: { "name": "Barak Hussein Le Obama" } They would get this: { "name": "Barak Hussein Le Obama" } If they only pulled the text from the tags from the input, they would get: { "first": "Barak", "last": "Le Obama" } This way the initial input "name" satisfies both desires for a single string name and for first/last significance names. I kept "Le Obama" above as an example with a last name with a space in it. This could further be applied internationally where people have different order for family names, so for Mr. Yao (basketball player): { "name": "Yao Ming" } And when you drop the tags you get the names in the right order: { "name": "Yao Ming" } Meadhbh Hamrick wrote: > not sure what you're going for here... > > the example is not valid XML, but i think your recommendation is > simply to use XML-like tags in the string that gets put inside the > transfer encoding, > > so if you encoded it with JSON it would be something like: > > { "name": "simonle bon"} > > or with XML, it would be encoded as: > > > > name > <first>simon</first><last>le > bon</last> > > > > ? > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Apr 6, 2010 at 7:32 AM, Dzonatas Sol wrote: > >> Barry Leiba wrote: >> >>> �Here's a >>> sampling of agent-identifiers, each within quotes just to make it >>> clear where they start and end: >>> � " Joshua Linden " >>> � ".Joshua.Linden." �(another way to represent the same thing) >>> � "/Joshua/Linden/" �(a third) >>> � "XJoshuaXLindenX" �(a fourth) >>> � " Melanie " �(an identifier with just one part) >>> � "rMelanier" �(the same, in another representation) >>> � ".Melanie." �(or less weirdly) >>> � " Barak Hussein Obama " � (here's one with three parts) >>> � "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit >>> if you're old enough to know who he is) >>> � "~le roy~barr~" �(Meadhbh's example with an embedded blank) >>> >>> >>> >> Another suggestion, if one used XML like tags: >> >> Barak Hussein Obama >> >> Then the string can be escaped into the name field. For those that don't >> want first/last, they just skip the tags. For those that only want >> first/last, they pull the text only within with first/last tags. >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > From josh@lindenlab.com Tue Apr 6 08:51:56 2010 Return-Path: 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 BE83E3A6811 for ; Tue, 6 Apr 2010 08:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.625 X-Spam-Level: X-Spam-Status: No, score=0.625 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 ByvVk04z4xIR for ; Tue, 6 Apr 2010 08:51:55 -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 A90453A67AE for ; Tue, 6 Apr 2010 08:51:55 -0700 (PDT) Received: by gyh4 with SMTP id 4so3531gyh.31 for ; Tue, 06 Apr 2010 08:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.144.11 with HTTP; Tue, 6 Apr 2010 08:51:50 -0700 (PDT) In-Reply-To: <4BBB4D6E.60600@gmail.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> <4BBB4D6E.60600@gmail.com> Date: Tue, 6 Apr 2010 08:51:50 -0700 Received: by 10.150.174.9 with SMTP id w9mr7880320ybe.0.1270569110633; Tue, 06 Apr 2010 08:51:50 -0700 (PDT) Message-ID: From: Joshua Bell To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd573d2807ddc0483936c05 Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:51:56 -0000 --000e0cd573d2807ddc0483936c05 Content-Type: text/plain; charset=UTF-8 Speaking for Linden: (1) For the purposes of VWRAP interop, it is acceptable to us to assume that a human readable agent identifier ("name") for Second Life can be coerced to and from a single string field. Today, SL firstname/lastname pairs are constrained to a subset of ASCII that disallows characters such as periods and spaces. Therefore, as has been mentioned, it is possible today to unambiguously encode an SL name as (firstname + "." + lastname) or (firstname + " " + lastname). (2) As mentioned at https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead and at https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up Linden is investigating modifications to "names" in SL. However, it is too early to comment on any details at this time. (3) That said, the investigative work for (2) is being done with the benefits of (1) held firmly in mind. (As with practically anything in the biz, this statement is not a contract or guarantee.) Therefore, from Linden's perspective, we can live with the proposed simplified requirements of a single string. If it becomes necessary to revisit that in the future we'll raise it. --000e0cd573d2807ddc0483936c05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking for Linden:

(1) For the purposes of = VWRAP interop, it is acceptable to us to assume that a human readable agent= identifier ("name") for Second Life can be coerced to and from a= single string field. Today, SL firstname/lastname pairs are constrained to= a subset of ASCII that disallows characters such as periods and spaces. Th= erefore, as has been mentioned, it is possible today to unambiguously encod= e an SL name as (firstname + "." + lastname) or (firstname + &quo= t; " + lastname).

(2) As mentioned at=C2=A0https://blogs.secondlife.com/community/features/blog/2010/01/03= /happy-new-year-looking-backlooking-ahead=C2=A0and at=C2=A0https://blogs.secondlife.com/community/features/blog= /2010/01/22/will-the-real-you-please-stand-up=C2=A0Linden is investigat= ing modifications to "names" in SL. However, it is too early to c= omment on any details at this time.=C2=A0

(3) That said, the investigative work for (2) is being = done with the benefits of (1) held firmly in mind. (As with practically any= thing in the biz, this statement is not a contract or guarantee.)

Therefore, from Linden's perspective, we can live w= ith the proposed simplified requirements of a single string. If it becomes = necessary to revisit that in the future we'll raise it.

--000e0cd573d2807ddc0483936c05-- From ohmeadhbh@gmail.com Tue Apr 6 09:10:36 2010 Return-Path: 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 2772B3A6976 for ; Tue, 6 Apr 2010 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] 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 0RcNz6F9RBO5 for ; Tue, 6 Apr 2010 09:10:34 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id AED473A686A for ; Tue, 6 Apr 2010 09:10:34 -0700 (PDT) Received: by qyk11 with SMTP id 11so45208qyk.13 for ; Tue, 06 Apr 2010 09:10:29 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=prsPNahjVSt2fDMsv2Llmd8fpJD6beG295rEtVimom8=; b=BiwGgpf7xSj47zq+algbq4ahekmU4cz2e1SpGtEGgiPPvcVx3xUb7FkfA+74rF5JsQ IShUw3zr/k8xO27bnuj0KeuLnSRn8Fz++GDaucubf3F5GGrE3DQwTxeNOTsaylhcxA7U ibCP/PrIL6D5rZjlI+FA9uTBuILrIewWzPsRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EM36eCzXFkU1hlBJfOORjNeF/T21l0MraAdKpQrmEvhzkfEudBviopncvlewWnoTJK cm9rtKm9pid138SRTGsCUycff8yxiknID/cUvB/lT4Dae3jcN5xuqRSaz+d9UPY2q3ZD Ak6WMnuq88CBe90d1XCJfXr8vB4/Aw7u6UxmY= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 09:02:10 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> <4BBB4D6E.60600@gmail.com> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 09:02:10 -0700 Received: by 10.229.224.79 with SMTP id in15mr12205611qcb.76.1270569750496; Tue, 06 Apr 2010 09:02:30 -0700 (PDT) Message-ID: To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:10:36 -0000 okay. removing the two name option from the draft. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 8:51 AM, Joshua Bell wrote: > Speaking for Linden: > (1) For the purposes of VWRAP interop, it is acceptable to us to assume t= hat > a human readable agent identifier ("name") for Second Life can be coerced= to > and from a single string field. Today, SL firstname/lastname pairs are > constrained to a subset of ASCII that disallows characters such as period= s > and spaces. Therefore, as has been mentioned, it is possible today to > unambiguously encode an SL name as (firstname + "." + lastname) or > (firstname + " " + lastname). > (2) As mentioned > at=A0https://blogs.secondlife.com/community/features/blog/2010/01/03/happ= y-new-year-looking-backlooking-ahead=A0and > at=A0https://blogs.secondlife.com/community/features/blog/2010/01/22/will= -the-real-you-please-stand-up=A0Linden > is investigating modifications to "names" in SL. However, it is too early= to > comment on any details at this time. > (3) That said, the investigative work for (2) is being done with the > benefits of (1) held firmly in mind. (As with practically anything in the > biz, this statement is not a contract or guarantee.) > Therefore, from Linden's perspective, we can live with the proposed > simplified requirements of a single string. If it becomes necessary to > revisit that in the future we'll raise it. > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From markl@lindenlab.com Tue Apr 6 10:05:56 2010 Return-Path: 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 35E303A68A4 for ; Tue, 6 Apr 2010 10:05:56 -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 Aq4NFqz7lCiP for ; Tue, 6 Apr 2010 10:05:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C1C863A6767 for ; Tue, 6 Apr 2010 10:05:54 -0700 (PDT) Received: by vws15 with SMTP id 15so40216vws.31 for ; Tue, 06 Apr 2010 10:05:49 -0700 (PDT) Received: by 10.220.127.96 with SMTP id f32mr3608908vcs.32.1270573549577; Tue, 06 Apr 2010 10:05:49 -0700 (PDT) Received: from nil.lindenlab.com ([38.99.52.137]) by mx.google.com with ESMTPS id 33sm53517642vws.10.2010.04.06.10.05.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 10:05:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) From: Mark Lentczner In-Reply-To: Date: Tue, 6 Apr 2010 10:05:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> To: vwrap X-Mailer: Apple Mail (2.1078) Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:05:56 -0000 On Apr 6, 2010, at 7:14 AM, Meadhbh Hamrick wrote: > what do systems that only understand xml 1.0 do if they encounter xml = 1.1? In the original XML sepc, systems were to signal an error and reject the = entire document. In the 5th revision, they are allowed to accept a = document with version "1.1" if and only if the document doesn't use = anything that isn't in 1.0. (see "Extensible Markup Language (XML)" = =A72.8) > the purpose of the version tag and the rule that you ignore but > preserve tags you don't understand is to provide the hope for > extension for situations we do not currently foresee. There is no such provision in XML. DTDs and schemas built with XMLSchema = or Relax generally don't have the facility to handle unexpected elements = and attributes (with the notable exceptions of XML applications that = expect namespace delimited elements in very particular places). XSLT = processing provides an facilities that match any element or attribute, = and reproduce it in the output, though that is thoroughly at the = discretion of the XSLT writer: They can just as easily drop such unknown = fragments. ---- Within the context of LLSD, the problem is that there is semantics to = the structures of array and map. For example, what does the application = reading the following binary sequence see: "[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "0" "]" ("z" here represents an unknown tag, and follows the recommendation that = all new unknown tags have a four byte length so that they can be = parsed.) Is that an array of three items, or two? What does "skipping but = preserving" mean? It is tempting to treat unknown tags as values. The = middle value is seen by the application as "undef". (Or, perhaps it is = seen as yet some other type we'd need to introduce into LLSD like = "foreign" with a value similar to binary: "1 byte of %x21") However, this leads to questions in maps: "{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.01 "!" = "}" This would be clear under the "value" interpretation, but what about: "{" %x00.00.00.01 "z" $x00.00.00.01 "!" "1" "}" Is that invalid (as the unknown tag appears in a non-value location) or = is it a "new key type", and hence is seen as the key "undef", only that = isn't a valid key. Is the whole key/value pair dropped? Does that make = this equivalent to the empty map? If we are to implement new structures, presumably they'd be wrapped up = inside one of these things with the count extending over past all the = values. For example, an unordered set might be introduced by: "w" %x00.00.00.0E %x00.00.00.02 "i" 0x00.00.01.3A "i" = 0x00.00.00.2A The first count includes all the bytes of the construct, the second = count is the number of elements of the set, the two elements are the = numbers 314 and 42. To an older application, this would be seen as the = "undef" value. ---- A wholly different choice of handling unknown tags is to simply ignore = it. This allows the older app to see a "substitute" value, and requires = that newer tags that want to be a value to have the semantic of "skip = the next value you read". Hence, the above examples might become: "[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "1" "0" "]" -- this is an array of three booleans, True, True, False, -- where there is a newer value type that substitutes for the = middle True "{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.01 "!" = "1" "}" -- this is a map of "abc" to True -- where there is a newer value type that substitutes for the = True "{" %x00.00.00.01 "z" $x00.00.00.01 "!" "k" $x00.00.00.03 "abc" = "1" "}" -- this is also a map of "abc" to True -- where there some newer tag that may have some unknown effect = on the map or the key "w" %x00.00.00.00 "[" %x00.00.00.02 "i" 0x00.00.01.3A "i" = 0x00.00.00.2A "]" -- an array of two integers, 314 and 42 -- where there is a tag in front that indicates to treat the = array as a set In these cases, the newer tags are simply ignored, and the remaining = tags form a valid binary serialization. It brings into question what it = would mean to "preserve" these. Perhaps, it a very delimited set of = future semantics ("all new tags must 'apply' to the next value or = key/value pair") LLSD implementations could attached these tags as = auxiliary data to existing LLSD types and constructs. ---- But for all the effort such definitions would take, I think it is better = to not allow them all, since I don't see a scenario where this is = favorable to content negotiation or protocol negotiation. In any such scenario, the "extension" would have to be minor enough to = not warrant protocol negotiation - the "extension" couldn't provide any = semantically important information: If newer code wants to pass an = unordered set rather than an array, then presumably the existing = semantics of the data block are that they array is to be treated as an = unordered set anyway. (If not, then we've got a new protocol.) If there = are new data types, whose values will be taken as "undef" in older code, = either that data is optional (in which case they should be under new map = keys) or it is crucial and hence needs to be under a new protocol. In short, it seems to me that ad hoc extension of LLSD at the layer of = elements within a serialization isn't that useful. Such extension should = occur at the content or protocol levels, both of which have existing = negotiation systems. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From ohmeadhbh@gmail.com Tue Apr 6 10:19:24 2010 Return-Path: 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 AED7D3A6850 for ; Tue, 6 Apr 2010 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] 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 C+zzKnYcSlRB for ; Tue, 6 Apr 2010 10:19:22 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 530C83A6803 for ; Tue, 6 Apr 2010 10:19:22 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so35166qwb.31 for ; Tue, 06 Apr 2010 10:19:17 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=L4yRyd5jhoQ+I0QIXYi39/lNwXFxblJO4FLWDpJPiRQ=; b=puOVkAsewy+ULbupKp5b1YFPl5qlQDEE6OI1EVBLf3KZoHadmnMxMnYSROBhewEJPY ZVCMK1Ruz0/t0WErY5q7RYO66E1Y+jTdLeS6BHvnU7KiMAOx37UOeVp+Ny4w34l5wEl+ nevDSZhOEC9YFKbmZT/TrrIXngmd09OsfCAio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nuQrHcCgFSgwdjaHNbunPotulAm22SJYAXWC8LEjDrIJi6QvFUTCF+QAdMyBRYNuuT HcBHCEiFiO/uaCD8eC3Jg/T0AtF+ZiJtb5TKwuM2ckjgQZj3e3AtTZtxN98R16yEgyIF N9BMiCT11420SMThltrwb5jQw4JHRVX7kPX8k= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 10:18:56 -0700 (PDT) In-Reply-To: References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 10:18:56 -0700 Received: by 10.229.98.129 with SMTP id q1mr525831qcn.100.1270574357122; Tue, 06 Apr 2010 10:19:17 -0700 (PDT) Message-ID: To: Mark Lentczner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:19:24 -0000 isn't this what "unknown" in wheat was used for? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 10:05 AM, Mark Lentczner wrote= : > On Apr 6, 2010, at 7:14 AM, Meadhbh Hamrick wrote: >> what do systems that only understand xml 1.0 do if they encounter xml 1.= 1? > > In the original XML sepc, systems were to signal an error and reject the = entire document. In the 5th revision, they are allowed to accept a document= with version "1.1" if and only if the document doesn't use anything that i= sn't in 1.0. (see "Extensible Markup Language (XML)" =A72.8) > >> the purpose of the version tag and the rule that you ignore but >> preserve tags you don't understand is to provide the hope for >> extension for situations we do not currently foresee. > > There is no such provision in XML. DTDs and schemas built with XMLSchema = or Relax generally don't have the facility to handle unexpected elements an= d attributes (with the notable exceptions of XML applications that expect n= amespace delimited elements in very particular places). XSLT processing pro= vides an facilities that match any element or attribute, and reproduce it i= n the output, though that is thoroughly at the discretion of the XSLT write= r: They can just as easily drop such unknown fragments. > > ---- > > Within the context of LLSD, the problem is that there is semantics to the= structures of array and map. For example, what does the application readin= g the following binary sequence see: > > =A0 =A0 =A0 =A0"[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "0" "]" > > ("z" here represents an unknown tag, and follows the recommendation that = all new unknown tags have a four byte length so that they can be parsed.) > > Is that an array of three items, or two? What does "skipping but preservi= ng" mean? It is tempting to treat unknown tags as values. The middle value = is seen by the application as "undef". (Or, perhaps it is seen as yet some = other type we'd need to introduce into LLSD like "foreign" with a value sim= ilar to binary: "1 byte of %x21") > > However, this leads to questions in maps: > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.0= 1 "!" "}" > > This would be clear under the "value" interpretation, but what about: > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "z" $x00.00.00.01 "!" "1" "}" > > Is that invalid (as the unknown tag appears in a non-value location) or i= s it a "new key type", and hence is seen as the key "undef", only that isn'= t a valid key. Is the whole key/value pair dropped? Does that make this equ= ivalent to the empty map? > > If we are to implement new structures, presumably they'd be wrapped up in= side one of these things with the count extending over past all the values.= For example, an unordered set might be introduced by: > > =A0 =A0 =A0 =A0"w" %x00.00.00.0E %x00.00.00.02 "i" 0x00.00.01.3A "i" 0x00= .00.00.2A > > The first count includes all the bytes of the construct, the second count= is the number of elements of the set, the two elements are the numbers 314= and 42. To an older application, this would be seen as the "undef" value. > > ---- > > A wholly different choice of handling unknown tags is to simply ignore it= . This allows the older app to see a "substitute" value, and requires that = newer tags that want to be a value to have the semantic of "skip the next v= alue you read". =A0Hence, the above examples might become: > > =A0 =A0 =A0 =A0"[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "1" "0" "]" > =A0 =A0 =A0 =A0-- this is an array of three booleans, True, True, False, > =A0 =A0 =A0 =A0-- where there is a newer value type that substitutes for = the middle True > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.0= 1 "!" "1" "}" > =A0 =A0 =A0 =A0-- this is a map of "abc" to True > =A0 =A0 =A0 =A0-- where there is a newer value type that substitutes for = the True > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "z" $x00.00.00.01 "!" "k" $x00.00.00.03 = "abc" "1" "}" > =A0 =A0 =A0 =A0-- this is also a map of "abc" to True > =A0 =A0 =A0 =A0-- where there some newer tag that may have some unknown e= ffect on the map or the key > > =A0 =A0 =A0 =A0"w" %x00.00.00.00 "[" %x00.00.00.02 "i" 0x00.00.01.3A "i" = 0x00.00.00.2A "]" > =A0 =A0 =A0 =A0-- an array of two integers, 314 and 42 > =A0 =A0 =A0 =A0-- where there is a tag in front that indicates to treat t= he array as a set > > In these cases, the newer tags are simply ignored, and the remaining tags= form a valid binary serialization. It brings into question what it would m= ean to "preserve" these. Perhaps, it a very delimited set of future semanti= cs ("all new tags must 'apply' to the next value or key/value pair") LLSD i= mplementations could attached these tags as auxiliary data to existing LLSD= types and constructs. > > ---- > > But for all the effort such definitions would take, I think it is better = to not allow them all, since I don't see a scenario where this is favorable= to content negotiation or protocol negotiation. > > In any such scenario, the "extension" would have to be minor enough to no= t warrant protocol negotiation - the "extension" couldn't provide any seman= tically important information: If newer code wants to pass an unordered set= rather than an array, then presumably the existing semantics of the data b= lock are that they array is to be treated as an unordered set anyway. (If n= ot, then we've got a new protocol.) If there are new data types, whose valu= es will be taken as "undef" in older code, either that data is optional (in= which case they should be under new map keys) or it is crucial and hence n= eeds to be under a new protocol. > > In short, it seems to me that ad hoc extension of LLSD at the layer of el= ements within a serialization isn't that useful. Such extension should occu= r at the content or protocol levels, both of which have existing negotiatio= n systems. > > =A0 =A0 =A0 =A0- Mark > > > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From stpeter@stpeter.im Tue Apr 6 11:01:54 2010 Return-Path: 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 0847928C0DF for ; Tue, 6 Apr 2010 11:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599] 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 Df6HRQJ-aCEL for ; Tue, 6 Apr 2010 11:01:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DD69F3A69C8 for ; Tue, 6 Apr 2010 11:01:45 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C0A040E15 for ; Tue, 6 Apr 2010 12:01:43 -0600 (MDT) Message-ID: <4BBB7705.4060206@stpeter.im> Date: Tue, 06 Apr 2010 12:01:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090809030207040500070002" Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:01:54 -0000 This is a cryptographically signed message in MIME format. --------------ms090809030207040500070002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: > okay. >=20 > if we're going to remove VWRAP from all current implementations, What does that mean? I thought we were trying to build VWRAP into implementations, not rip it out. :) > i > vote we remove MD5 from the auth spec and replace it with a MIC with > better security properties, like SHA224 or SHA256. +1 to more secure authentication. My quick reading of the authentication draft led me to think that it needed a thorough review, but unfortunately I haven't had time to do that yet. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090809030207040500070002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwNjE4MDE0MVowIwYJKoZIhvcNAQkEMRYEFIqfNNoN+FPdord5Nwm1 CKdluQ/4MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJLPCia1qWoie+oDvgkS8NN8NTjx+PXeX86par8PQ VjfF706qFNSsDlItRUmrOE7zRnpPbkuzlXMk78gYaYtbPEJQSNIH8TodmtE3hNLK98KcZ0ML U6Sk/4eto72de7DQYscD0dWom6ujfWflRuKvna3mArSP7ZxnrbyeeMnkw3h8as/VdpqyaaDb Enn623Npyp72LE62SCr0pW6SzqX36kV5F70TsOn0n21soTBIt76FhWe3K9uiPlvwPkRbT7h+ gda2JKKDTDVXs2oR4/4R/xW+4cyfQBbjF8Dizk90PROqyY5A6q2T2zCiz9fPRSmsJGgAG+9a EZUNqE7Xog0CKQAAAAAAAA== --------------ms090809030207040500070002-- From rbarnes@bbn.com Tue Apr 6 11:07:48 2010 Return-Path: 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 D6ABC28C0F0 for ; Tue, 6 Apr 2010 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] 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 msZnfTuc-VUX for ; Tue, 6 Apr 2010 11:07:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id ABD9E3A69D2 for ; Tue, 6 Apr 2010 11:07:42 -0700 (PDT) Received: from [192.1.255.171] (port=51568 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzDBb-000Ogo-Hh; Tue, 06 Apr 2010 14:07:39 -0400 Message-Id: From: Richard Barnes To: Peter Saint-Andre In-Reply-To: <4BBB7705.4060206@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 14:07:38 -0400 References: <4BBB7705.4060206@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:07:49 -0000 >> okay. >> >> if we're going to remove VWRAP from all current implementations, > > What does that mean? I thought we were trying to build VWRAP into > implementations, not rip it out. :) Right, I think the right approach is to think about adding a "VWRAP compatibility layer" to existing implementations, and keeping that layer as simple as possible (but no simpler!). That raises the question of where changing hashes falls w.r.t. simplicity. It might seem like you would want to keep MD5 so that the compatibility layer wouldn't have to re-hash things. However, it already seems like there's going to be a need for the compatibility layer to translate names, which will (presumably) break signatures already. So since there's already need to re-hash, it's not a big deal to re-hash with a different hash function. --Richard >> i >> vote we remove MD5 from the auth spec and replace it with a MIC with >> better security properties, like SHA224 or SHA256. > > +1 to more secure authentication. > > My quick reading of the authentication draft led me to think that it > needed a thorough review, but unfortunately I haven't had time to do > that yet. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap From carlo@alinoe.com Tue Apr 6 11:23:06 2010 Return-Path: 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 20CAE28C0EE for ; Tue, 6 Apr 2010 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 AQcZUGUDZt4o for ; Tue, 6 Apr 2010 11:23:04 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 1511C28C10A for ; Tue, 6 Apr 2010 11:16:39 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406181636.ZKKG9419.viefep11-int.chello.at@edge02.upcmail.net>; Tue, 6 Apr 2010 20:16:36 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id 2JGZ1e03J0FlQed02JGaHo; Tue, 06 Apr 2010 20:16:36 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1NzDKD-0001lo-7P; Tue, 06 Apr 2010 20:16:33 +0200 Date: Tue, 6 Apr 2010 20:16:33 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20100406181633.GA6424@alinoe.com> References: <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> <4BBB4D6E.60600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=29LKRTqBM1RB9flqW432dy+DURWvGDGZbgxXOX7FpSE= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=A1X0JdhQAAAA:8 a=BjFOTwK7AAAA:8 a=SohSSitP8kvTnixF3TwA:9 a=G1jm07bj_-Au3z6I6hEA:7 a=MXjOzoU7AiCD4BM1lIXai37NS6sA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:23:06 -0000 On Tue, Apr 06, 2010 at 09:02:10AM -0700, Meadhbh Hamrick wrote: > okay. removing the two name option from the draft. There is no need to remove the notion of "agentID" versus "accountID" I think. Both are thus different that I can imagine there is the need for an overlap period, or else indeed very specific encoding would be needed(?) for the one-string. [ Perhaps it should be noted however that in theory it is possible to use the one string as a custom xml message in itself (like Dzontas example). This would fall completely outside the realm of VWRAP, but it does raise the question of there really is a need for two different types of login strings in VWRAP therefore. The string, as defined in VWRAP, could contain (as defined by whoever the provider is) for example: agentID Firstname Lastname, or accountID email@address.example.com or any encoding a provider wishes.] I am assuming you mean that in the draft agentID will be a single string, just like accountID? -- Carlo Wood From ohmeadhbh@gmail.com Tue Apr 6 11:34:53 2010 Return-Path: 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 4DA2F3A6AFB for ; Tue, 6 Apr 2010 11:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] 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 487sMTxY30FJ for ; Tue, 6 Apr 2010 11:34:52 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 34E7F3A6A05 for ; Tue, 6 Apr 2010 11:30:14 -0700 (PDT) Received: by qyk11 with SMTP id 11so188685qyk.13 for ; Tue, 06 Apr 2010 11:30:08 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=zxUpethlSP9JueXk/rTqosgMeWgrHPid5A90y3L0PiM=; b=jYiPHxSuH3R8VbVcBlMQ35pm6SLoDF0iHgZlue+toumWNUj22nddYZ99uFWIaGLrTZ 8xVGV33M/Y5R0fCFySk3tHPivlGlR64LtEoVlH515HJnOjdoupECqSJu7y8MMeklFh9+ +Zy2+75NeFIuNExJBqo73SsPCh1BjLhYUiph0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PLUVoZugnM5x64pMZ3Tx8UPcFYohOpnvORsBGlsfERz0yA5IWR6Lb/hwNhFffYbpq7 IpKBx6h3lQ3UldA1JrVtYXbzXC2CTRiVdxLimekmHrjrqcmEhC2GgD1DPYj+wKse3XiR aQjhf+sLWEFL+IP0i97cdCVlutk7quJTqvvIg= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 11:29:45 -0700 (PDT) In-Reply-To: References: <4BBB7705.4060206@stpeter.im> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 11:29:45 -0700 Received: by 10.229.99.143 with SMTP id u15mr6352106qcn.105.1270578605647; Tue, 06 Apr 2010 11:30:05 -0700 (PDT) Message-ID: To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:34:53 -0000 i don't think we're proposing using digital signatures in the authentication draft. i would also point out that "simply adding a VWRAP compatibility layer" would introduce non-zero engineering costs to both LL and the OpenSim community. but what is worse, is that it would stray from our charter. the objective of this group is, if you will recall, to make standards for interoperability between hosts that implement a type of virtual experience we sometimes refer to as "second lifelike." it's not SL, but something with a similar architecture. it is NOT a compatibility layer for arbitrary virtual world protocols. we tried that with MMOX, it did not work. VWRAP !=3D MMOX. what i am mostly concerned about is, that if we don't have an idea for how close we wish to stick to existing implementations, there's no telling where we'll wind up. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 11:07 AM, Richard Barnes wrote: >>> okay. >>> >>> if we're going to remove VWRAP from all current implementations, >> >> What does that mean? I thought we were trying to build VWRAP into >> implementations, not rip it out. :) > > Right, I think the right approach is to think about adding a "VWRAP > compatibility layer" to existing implementations, and keeping that layer = as > simple as possible (but no simpler!). > > That raises the question of where changing hashes falls w.r.t. simplicity= . > =A0It might seem like you would want to keep MD5 so that the compatibilit= y > layer wouldn't have to re-hash things. =A0However, it already seems like > there's going to be a need for the compatibility layer to translate names= , > which will (presumably) break signatures already. =A0So since there's alr= eady > need to re-hash, it's not a big deal to re-hash with a different hash > function. > > --Richard > > > > >>> i >>> vote we remove MD5 from the auth spec and replace it with a MIC with >>> better security properties, like SHA224 or SHA256. >> >> +1 to more secure authentication. >> >> My quick reading of the authentication draft led me to think that it >> needed a thorough review, but unfortunately I haven't had time to do >> that yet. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> _______________________________________________ >> 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 > From ohmeadhbh@gmail.com Tue Apr 6 11:34:54 2010 Return-Path: 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 1D1703A6A05 for ; Tue, 6 Apr 2010 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 zbgjqr5qKKEy for ; Tue, 6 Apr 2010 11:34:53 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 748BE3A6A0C for ; Tue, 6 Apr 2010 11:30:22 -0700 (PDT) Received: by mail-qy0-f181.google.com with SMTP id 11so188685qyk.13 for ; Tue, 06 Apr 2010 11:30:20 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type; bh=NRRr5EcnW1LdNrz2/GadWb0Wf5WGU6MoprIA90vCBZc=; b=OPBPgMuOBH9AMZ9ydmk6Ce+DP+IU+KbqogedjRK1raIdEeyUNhErxko5W+VrOt5Wal iD4Es5cSo632h9+1IZEqCmaK4/8zXM84dNJo8xV5GBJtWDp7FTqLId1uteD6e8EoxpCu jHgzQ6u5EY6KCu6pY6sIu/uNNlVnEkgWNKt4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SumLDlBk7n3URj7r0kTzykb20tVfJTZHA17ZODAF+tn8X+anfTpu0T3Aq2c6tF55ev A9V+U63DGWJVun8TYOpVV4/sq82q+4Vx7mGhpvJMbwKaIedDa5vbH2bux4NnHqqPsaTk XL6qjTSNjOLlkP9DraMg/2gMv0hte1yVfCfSs= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 11:22:58 -0700 (PDT) In-Reply-To: <4BBB7705.4060206@stpeter.im> References: <4BBB7705.4060206@stpeter.im> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 11:22:58 -0700 Received: by 10.229.111.81 with SMTP id r17mr12638538qcp.32.1270578198299; Tue, 06 Apr 2010 11:23:18 -0700 (PDT) Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:34:54 -0000 we need clarification about how much of the second life legacy protocol will be used in VWRAP. for instance. second life stores the MD5 hash of user passwords in the user database and uses it to authenticate users when logging in. but MD5 has some significant problems which were exacerbated several years ago when there was a security breach of linden's servers. so if we simply said "we're going to ditch MD5 in favor of SHA256" there would be a problem with reverse compatibility of the authentication data. this is because you can't generate the pre-image from an MD5 MIC and then use it to generate a SHA256 MIC. (or you can't do that in a way that insures that your MD5 pre image is the same as the password.) so in other words, there is an action we could take in this group that COULD make it very difficult for linden and presumably existing OpenSim instances to use the authentication protocol. so the question is, to which degree do we add an engineering burden to existing implementations that would like to adopt this group's output? the question of the two string identifier is a good one. linden could probably make systems that adhere to all sorts of different changes. but to what degree to we make it easy for existing implementers vs. the desires of people who have yet to build and implementation? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre wrote: > On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: >> okay. >> >> if we're going to remove VWRAP from all current implementations, > > What does that mean? I thought we were trying to build VWRAP into > implementations, not rip it out. :) > >> i >> vote we remove MD5 from the auth spec and replace it with a MIC with >> better security properties, like SHA224 or SHA256. > > +1 to more secure authentication. > > My quick reading of the authentication draft led me to think that it > needed a thorough review, but unfortunately I haven't had time to do > that yet. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Tue Apr 6 11:42:11 2010 Return-Path: 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 CB7233A68F3 for ; Tue, 6 Apr 2010 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] 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 URhE6vA6-1yC for ; Tue, 6 Apr 2010 11:42:10 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 8E80B3A6801 for ; Tue, 6 Apr 2010 11:40:01 -0700 (PDT) Received: by qyk11 with SMTP id 11so198630qyk.13 for ; Tue, 06 Apr 2010 11:39:59 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+PkhhshizaBxqvoxS90xHJMIfKxxRDZnyScppPo6nYM=; b=qKpY/eJXakMMBPAl3C3fQxzeL9RYrGSiJ/P2AKVpAK93SHM7Ea4YsAMUpEXEOO8NM5 S/zbsfX5fKC+dHCHgnP732QN8Ex+CNpPGNUvO/0yjOvvfjmnjYIBQnboSeJD/NfqQb1L 98t6EzHK1M+9buC3ieaYprzMbUPdw6HTt7hOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jMaAEyArmXlACqlgbLj3oZiZbt74IJa+KbW9G0FPIca0HVMspWHOpdmuevihvZuMuM 1vmHyFrdsXuY0pHZ7NHeHz7MximuCEW+9tERwOclx2jJNvn0RRo41dWRWCjxYls391Mq wcwBP9CztV/HokjM+WUhsnWNuVAQ1Fvu3g/Gs= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 11:39:39 -0700 (PDT) In-Reply-To: References: <201003282229.21448.bobby@sharedrealm.com> <80CE754B-4BF5-4DA1-A63C-DD18695BF4D0@lindenlab.com> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 11:39:39 -0700 Received: by 10.229.190.133 with SMTP id di5mr4623202qcb.23.1270579199155; Tue, 06 Apr 2010 11:39:59 -0700 (PDT) Message-ID: To: Mark Lentczner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap Subject: Re: [vwrap] [ogpx] type-system : version tag and handling unknown tags X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:42:11 -0000 mark, XML defines "well formed" as being distinct from being "valid". up til now we have been talking on the list about what to do with documents that are not "well formed." well-formed documents do not refer to a schema, and as i am sure you are aware, do not check or enforce a sequence of tags. that is something that's done to check the document's validity. are we suggesting that the two should be conflated (or well-formedness be ignored) for the purposes of LLSD serialization? should we NEVER allow for the extension of the LLSD XML schema? it just seems a bit short sighted to say the equivalent of "we know of all uses for this serialization scheme at the current moment and do not need to add the capability for expansion." -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 10:05 AM, Mark Lentczner wrote= : > On Apr 6, 2010, at 7:14 AM, Meadhbh Hamrick wrote: >> what do systems that only understand xml 1.0 do if they encounter xml 1.= 1? > > In the original XML sepc, systems were to signal an error and reject the = entire document. In the 5th revision, they are allowed to accept a document= with version "1.1" if and only if the document doesn't use anything that i= sn't in 1.0. (see "Extensible Markup Language (XML)" =A72.8) > >> the purpose of the version tag and the rule that you ignore but >> preserve tags you don't understand is to provide the hope for >> extension for situations we do not currently foresee. > > There is no such provision in XML. DTDs and schemas built with XMLSchema = or Relax generally don't have the facility to handle unexpected elements an= d attributes (with the notable exceptions of XML applications that expect n= amespace delimited elements in very particular places). XSLT processing pro= vides an facilities that match any element or attribute, and reproduce it i= n the output, though that is thoroughly at the discretion of the XSLT write= r: They can just as easily drop such unknown fragments. > > ---- > > Within the context of LLSD, the problem is that there is semantics to the= structures of array and map. For example, what does the application readin= g the following binary sequence see: > > =A0 =A0 =A0 =A0"[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "0" "]" > > ("z" here represents an unknown tag, and follows the recommendation that = all new unknown tags have a four byte length so that they can be parsed.) > > Is that an array of three items, or two? What does "skipping but preservi= ng" mean? It is tempting to treat unknown tags as values. The middle value = is seen by the application as "undef". (Or, perhaps it is seen as yet some = other type we'd need to introduce into LLSD like "foreign" with a value sim= ilar to binary: "1 byte of %x21") > > However, this leads to questions in maps: > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.0= 1 "!" "}" > > This would be clear under the "value" interpretation, but what about: > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "z" $x00.00.00.01 "!" "1" "}" > > Is that invalid (as the unknown tag appears in a non-value location) or i= s it a "new key type", and hence is seen as the key "undef", only that isn'= t a valid key. Is the whole key/value pair dropped? Does that make this equ= ivalent to the empty map? > > If we are to implement new structures, presumably they'd be wrapped up in= side one of these things with the count extending over past all the values.= For example, an unordered set might be introduced by: > > =A0 =A0 =A0 =A0"w" %x00.00.00.0E %x00.00.00.02 "i" 0x00.00.01.3A "i" 0x00= .00.00.2A > > The first count includes all the bytes of the construct, the second count= is the number of elements of the set, the two elements are the numbers 314= and 42. To an older application, this would be seen as the "undef" value. > > ---- > > A wholly different choice of handling unknown tags is to simply ignore it= . This allows the older app to see a "substitute" value, and requires that = newer tags that want to be a value to have the semantic of "skip the next v= alue you read". =A0Hence, the above examples might become: > > =A0 =A0 =A0 =A0"[" %x00.00.00.03 "1" "z" %x00.00.00.01 "!" "1" "0" "]" > =A0 =A0 =A0 =A0-- this is an array of three booleans, True, True, False, > =A0 =A0 =A0 =A0-- where there is a newer value type that substitutes for = the middle True > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "k" $x00.00.00.03 "abc" "z" $x00.00.00.0= 1 "!" "1" "}" > =A0 =A0 =A0 =A0-- this is a map of "abc" to True > =A0 =A0 =A0 =A0-- where there is a newer value type that substitutes for = the True > > =A0 =A0 =A0 =A0"{" %x00.00.00.01 "z" $x00.00.00.01 "!" "k" $x00.00.00.03 = "abc" "1" "}" > =A0 =A0 =A0 =A0-- this is also a map of "abc" to True > =A0 =A0 =A0 =A0-- where there some newer tag that may have some unknown e= ffect on the map or the key > > =A0 =A0 =A0 =A0"w" %x00.00.00.00 "[" %x00.00.00.02 "i" 0x00.00.01.3A "i" = 0x00.00.00.2A "]" > =A0 =A0 =A0 =A0-- an array of two integers, 314 and 42 > =A0 =A0 =A0 =A0-- where there is a tag in front that indicates to treat t= he array as a set > > In these cases, the newer tags are simply ignored, and the remaining tags= form a valid binary serialization. It brings into question what it would m= ean to "preserve" these. Perhaps, it a very delimited set of future semanti= cs ("all new tags must 'apply' to the next value or key/value pair") LLSD i= mplementations could attached these tags as auxiliary data to existing LLSD= types and constructs. > > ---- > > But for all the effort such definitions would take, I think it is better = to not allow them all, since I don't see a scenario where this is favorable= to content negotiation or protocol negotiation. > > In any such scenario, the "extension" would have to be minor enough to no= t warrant protocol negotiation - the "extension" couldn't provide any seman= tically important information: If newer code wants to pass an unordered set= rather than an array, then presumably the existing semantics of the data b= lock are that they array is to be treated as an unordered set anyway. (If n= ot, then we've got a new protocol.) If there are new data types, whose valu= es will be taken as "undef" in older code, either that data is optional (in= which case they should be under new map keys) or it is crucial and hence n= eeds to be under a new protocol. > > In short, it seems to me that ad hoc extension of LLSD at the layer of el= ements within a serialization isn't that useful. Such extension should occu= r at the content or protocol levels, both of which have existing negotiatio= n systems. > > =A0 =A0 =A0 =A0- Mark > > > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From carlo@alinoe.com Tue Apr 6 11:57:51 2010 Return-Path: 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 A85C43A67E3 for ; Tue, 6 Apr 2010 11:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.726 X-Spam-Level: X-Spam-Status: No, score=0.726 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 rM10yokGX0pM for ; Tue, 6 Apr 2010 11:57:50 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id DD3383A691D for ; Tue, 6 Apr 2010 11:57:47 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100406185743.XDHY14297.viefep15-int.chello.at@edge03.upcmail.net>; Tue, 6 Apr 2010 20:57:43 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id 2Jxf1e04c0FlQed03JxgGQ; Tue, 06 Apr 2010 20:57:43 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1NzDxz-000256-FN; Tue, 06 Apr 2010 20:57:39 +0200 Date: Tue, 6 Apr 2010 20:57:39 +0200 From: Carlo Wood To: trac@localhost.amsl.com Message-ID: <20100406185739.GB6424@alinoe.com> References: <059.7033e411bbd74dc481125cfa915c0bb4@tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <059.7033e411bbd74dc481125cfa915c0bb4@tools.ietf.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=oZn3SlGMZCkA:10 a=38zWk6xDZSoA:10 a=IkcTkHD0fZMA:10 a=BjFOTwK7AAAA:8 a=dnZDWKFMRF2nQYMzfdEA:9 a=7rlRfV853C8fyKl3ry0A:7 a=twfO-gDFzDROuuVIIjFvjmwdkGoA:4 a=QEXdDO2ut3YA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] #12: Event-like resource type for LLIDL X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:57:51 -0000 I'm not sure if I follow what an "event" is. I think that the only thing we have are states or state variables that are distributed. A single state variable has a single authority (running program on some machine) and only that authority can change the state of that variable. At that moment it should tell others that need to know that the state changed, that is changed (and into what). Confirmation of such messages is needed to be sure that there is no desync, if and only if the messages travel over a lossy line, ie if UDP is being used. If some other machine then the authority wants to change a state variable, it should send a request to the authority and assume the variable has NOT changed, until it receives an update from the authority that the change has been made. The reason for this approach is because otherwise it is impossible to keep track of non-commuting operators. As an example lets consider the rotation of an in-world object (rotating something is non-commuting). The authority of the rotation variables (a vector) will be the sim where the object is 'rezzed'. If two different sources request to rotate the object at the same time and already update their local "cached value" when sending it, things will get desynced: Let the vector start as x,y,x = 0,0,1 pointing up. Let operator R1 be a 90 degree rotation around the x-axis (z = y and y = -z) and operator R2 be a 90 degree rotation around the y-axis (z = x and x = -z) Start condition: host1 ------ sim ------ host2 0,0,1 0,0,1 0,0,1 host1 issues a rotation R1 and updates the local copy immediately, host2 issues a rotation R2 and updates the local copy immediately: host1 --R1---> sim <---R2-- host2 0,-1,0 0,0,1 -1,0,0 Suppose that R1 arrives at the sim first, the sim will then send out the rotation to host2: host1 -------- sim <---R2-- host2 ---R1--> 0,-1,0 0,-1,0 -1,0,0 Neither of the rotation have a visible effect on the remaining states (-1,0,0 rotated around the x-axis is still -1,0,0 and 0,-1,0 rotated around the y-axis is still 0,-1,0). Thus when finally both R1 and R2 have reached all hosts we end up with: host1 -------- sim -------- host2 0,-1,0 0,-1,0 -1,0,0 A desync. Therefore host1 and host2 may only send requests and do NOT change the value of their internal cache: host1 --R1---> sim <---R2-- host2 0,0,1 0,0,1 0,0,1 host1 <--R1,R2-- sim --R1,R2--> host2 0,0,1 0,-1,0 0,0,1 host1 -------- sim -------- host2 0,-1,0 0,-1,0 0,-1,0 If what you proposed here: On Wed, Mar 31, 2010 at 09:46:31PM -0000, vwrap issue tracker wrote: > --------------------------------+------------------------------------------- > Reporter: markl@… | Owner: markl@… > Type: enhancement | Status: new > Priority: major | Milestone: > Version: | Severity: - > Keywords: TypeSystem | > --------------------------------+------------------------------------------- > There didn't appear to be clear consensus on if LLIDL needed an "event- > like" resource type. These would be resources that had a body with the > request, but expected nothing other than confirmation of receipt in the > response. means that upon a request the sim will not reply with a responding state, but merely with an ACK, then the requesting host has to remember the operator and apply it on the state at the moment he receives the acknowledge. For example, host1 requests R1, then it receives the update R2 and finally receives the acknowledge for the R1 request. Clearly it has to apply the operators in the order: first R2 then R1. -- Carlo Wood From lenglish5@cox.net Tue Apr 6 13:48:48 2010 Return-Path: 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 8CB593A6A3B for ; Tue, 6 Apr 2010 13:48:48 -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 HUbKy2PscIKR for ; Tue, 6 Apr 2010 13:48:46 -0700 (PDT) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 30FA53A69A9 for ; Tue, 6 Apr 2010 13:47:51 -0700 (PDT) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao106.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100406204749.TXQQ1296.fed1rmmtao106.cox.net@fed1rmimpo03.cox.net>; Tue, 6 Apr 2010 16:47:49 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id 2Lnk1e00G2l1Ksg04Lnkmz; Tue, 06 Apr 2010 16:47:44 -0400 X-VR-Score: -184.00 X-Authority-Analysis: v=1.1 cv=yjuDh3Ma92GrVaJxYD7gfORM7ilP1Knqouyx6SOEBcg= c=1 sm=1 a=JplFsMs8w-wA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=gjM9v_0UAAAA:8 a=cexIBkohAAAA:8 a=mng0MaQmAAAA:8 a=W1N-uV7Q_0gxI9FtEzkA:9 a=hswKGbfY3IV7rFZhlkAA:7 a=J0eqwYsVHYLNY0nZWNq5ld7RTUgA:4 a=QEXdDO2ut3YA:10 a=Y110doR01EYA:10 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4BBB9DF0.9070706@cox.net> Date: Tue, 06 Apr 2010 13:47:44 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Carlo Wood References: <059.7033e411bbd74dc481125cfa915c0bb4@tools.ietf.org> <20100406185739.GB6424@alinoe.com> In-Reply-To: <20100406185739.GB6424@alinoe.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, trac@localhost.amsl.com Subject: Re: [vwrap] #12: Event-like resource type for LLIDL X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:48:48 -0000 Carlo Wood wrote: > I'm not sure if I follow what an "event" is. > > [...] > > means that upon a request the sim will not reply with a responding > state, but merely with an ACK, then the requesting host has to remember > the operator and apply it on the state at the moment he receives the > acknowledge. > > For example, host1 requests R1, then it receives the update R2 and > finally receives the acknowledge for the R1 request. Clearly it > has to apply the operators in the order: first R2 then R1. > > You might want to look at the Teatime architecture as implemented in Croquet/Cobalt for one way in which this is handled. Each user of a Cobalt "client" initiates an event in its own copy of the simulator-client, which sends the event to the central authority, which in tun broadcasts that event to the shared simulation in the order that the event is received. The unique thing about Cobalt is that every simulator is running on the same virtual machine with 100% identical behavior at the ISA level and the "events" are standard Smalltalk OOP programming messages sent to the copy of each smalltalk object as though they were receiving messages directly from another object locally. No event is recognized in any client-simulator until it is authorized by the central dispatcher, not even the client where the user chose to initiate an avatar movement can render it taking a step until the dispatcher broadcasts that event and it is received by each client. One upside is that only simple OOP messages are sent, often with less overhead per event than sending large amounts of state data. One downside is the requirement that ALL clients' simulators are running 100% identical byte-code interpreters, along with a programming model that assumes that all objects are collaborative whiteboards (with some exception made for handling avatar actions I'm guesing) so the shared illusion of a SL life economy is virtually impossible, under anything resembling the current Croquet/Cobalt implementation. http://opencroquet.org/index.php/Overview http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf http://opencroquet.org/index.php/Croquet_SDK However, there is room for _ad hoc_ implementations of Teatime or Teatime-like services in a VWRAP metaverse. Consider the obvious use-case of a genuine in-world collaborative whiteboard that uses Croquet/Cobalt teatime (or something similar) as the collaborative networking architecture to share drawing commands between MoaP objects. People could subscribe as collaborators and indulge in 100% coordinated interactions in any level of sophistication, or they could subscribe as the audience and simply observer the interactions, perhaps via a broadcast read-only VNC session or a readonly teatime equivalent. The interactions could range from simple drawing apps ala the flash/java based whiteboards you see on webpages, to more complicated setups like Kansas (written in Self) http://research.sun.com/ics/kansas.html or Nebraska (a partial port to Squeak smalltalk) http://wiki.squeak.org/squeak/1356 implemented on prims in-world or in proximity-sensative HUDs or even as some kind of ghostly physics simulation where physics and other behavior is controlled by a different setup than the normal central VRWAP server or as special physics/combat interactions governed by client-side simulations. Squeak smalltalk was chosen for the implementation of Croquet for several reasons, including fast prototyping but also because it implements 100% identical VM behavior cross-platform (including floating point calculations) which is vital for maintaining totally coordinated shared simulations using distributed programming. It should be easily possible to use the Croquet/teatime/Cobalt island system to control simple objects (e.g. whiteboards and combat-physics simulators) using embedded squeak (suitably sandboxed to only generate safe messages) or in circumstances where 100% identical behavior is not needed, other languages and strategies could be used instead. The demo project I'm working on would take an existing Cobalt world and render it on a prim using a simple modification of the Media plugin. This would allow for amusing things like teleconferencing between different virtual worlds. More practical scenarios would be to use a similar strategy to implement whiteboards ala Kansas/Nebraska, combat systems, shared line dancing, music collaboration, etc. The pattern (assuming Squeak here, though you can do it with less precise coordination using other languages and systems): SL client <=> media on a prim <=> [rendering/keyboard i/o to Cobalt world-client] <=> teatime/cobalt island dispatcher/event handler <=> [Cobalt world-client interactions with rendering/keyboard i/o] <=> media on a prim <=> SL client Put any kind of event handler/generator you like in the [ ], and you have, at least for those specific events, potentially 100% identical behavior even in a VWRAP metaverse. Note that the SL client would consume and generate events (images/keypresses/combat messages/etc) sent to the teatime system but that aside from these specific points of interaction, the slavish control of a Cobalt shared world woudn't be implemented, leaving the more liberal behavior of a VWRAP world intact. If a client doesn't get the message that a drawing was done, or that a dance step isn't to be initiated or that a physics simulation for ghosted prims hasn't changed their state, it only affects the specific view of that aspect of the shared simulation, not the entire simulator's. Lawson From barryleiba.mailing.lists@gmail.com Tue Apr 6 14:25:16 2010 Return-Path: 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 A8B3B3A69FE for ; Tue, 6 Apr 2010 14:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 w0kdFo5hXqcE for ; Tue, 6 Apr 2010 14:25:16 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2B6643A6A07 for ; Tue, 6 Apr 2010 14:25:09 -0700 (PDT) Received: by fxm5 with SMTP id 5so386342fxm.29 for ; Tue, 06 Apr 2010 14:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type; bh=Pq2cUfxk2qRKgOajvAteBpqjb8jLsjYIZufOMs24NlU=; b=vI6eH7oTKquXf/8cN996GNJP0Ff09PkLt0GETyDiFxYMTw+3AiolVpvasGB0Pyyv9E +AB4XwSC2jvNw26BBWkSZI7iMq3wWXskjZIeL5e1tmJ0tYf5V8wdNG8egrW6Q9pzxIgA 2/FsAYMRXj97WAPrOOTvxdEBXkjuJ8zmxGy7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=db/7gJfS7TROj+A44z0Zxtdj1P8SYuubXZZLXlScYCtbX9Iu0EXIlF4Xovt6ALEyxr crFVzrPVWkpOV4PxqUe5ZzTryzjHEJx4pcI95As76/HEwl5Ktkv0pXePv1dgdJDgP/xP qsak48NUuRXBW7SZn3VSn8Fw5SJ1Y4XlWgY/w= MIME-Version: 1.0 Received: by 10.223.112.15 with HTTP; Tue, 6 Apr 2010 14:25:01 -0700 (PDT) In-Reply-To: References: <4BBB7705.4060206@stpeter.im> Date: Tue, 6 Apr 2010 17:25:01 -0400 Received: by 10.223.62.83 with SMTP id w19mr8079820fah.22.1270589101622; Tue, 06 Apr 2010 14:25:01 -0700 (PDT) Message-ID: From: Barry Leiba To: Meadhbh Hamrick Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:25:16 -0000 > so if we simply said "we're going to ditch MD5 in favor of SHA256" > there would be a problem with reverse compatibility of the > authentication data. this is because you can't generate the pre-image > from an MD5 MIC and then use it to generate a SHA256 MIC. (or you > can't do that in a way that insures that your MD5 pre image is the > same as the password.) The usual way to handle this is with a migration process. Credentials are re-hashed with the new algorithm when they're changed, over time. After a time, there's a cutoff and users are forced to change their credentials the next time they log in. The old login has to be supported as long as there are users who have not yet changed... or until someone decides to toss those users. Barry From ohmeadhbh@gmail.com Tue Apr 6 15:01:51 2010 Return-Path: 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 329333A699A for ; Tue, 6 Apr 2010 15:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] 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 Zzs9tczTfMCM for ; Tue, 6 Apr 2010 15:01:50 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id E027F3A68A5 for ; Tue, 6 Apr 2010 15:01:43 -0700 (PDT) Received: by qyk11 with SMTP id 11so393348qyk.13 for ; Tue, 06 Apr 2010 15:01:38 -0700 (PDT) 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 :from:date:received:message-id:subject:to:content-type :content-transfer-encoding; bh=Bg4M/Mf5h24ZaVNctX8N7lkfVxEIzBNUJftOSYwzAl4=; b=tjeX4fd7VadrRqHOWJvotLDw40oolCwcN0vHzpHMM4CSBB51lRc2sSfJMRq4Gcrrdk VCdrdEiKtPUO5l8K/HeiZV2794NY81elWgy3YUttRRIdTv4v2wzWlbKNVCDvm7LD14pN MUahlYnx8v8GSw/F1n6R4B1XNy23ctAyT7DBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=ccuR1qQRIBz63WbgfxNNFUeL3/VohrDM0t8ilZkLrmBbie5eoYmkkLcaH9R9K1ei6E HVg/ow4TYpXM+gM4GF+Md0mX0bxsYVOgc0ispaQMfpBYmi2028e+e6UB7xpWvCAjJqEy v1ySmGbty0fiaLR33ozzSLQ/X0PULAetBpvuk= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 15:01:18 -0700 (PDT) In-Reply-To: References: <4BBB7705.4060206@stpeter.im> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 15:01:18 -0700 Received: by 10.229.241.66 with SMTP id ld2mr1233399qcb.78.1270591298173; Tue, 06 Apr 2010 15:01:38 -0700 (PDT) Message-ID: To: Barry Leiba , vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:01:51 -0000 yes. but until the migration is complete for all users, do we implement the new spec with SHA256? do well tell users they have until a certain date to login and regenerate the hash? it would be nice if we could have SOME reverse compatibility so we could use the maintenance facility to do the rehashing. so you could: 1. on a certain date, stop returning seed caps from a successful login with MD5, but include a maintenance cap with an URL pointing to a page users can use to rehash their password. 2. at the web page, users re-enter their password, it's hashed with SHA256 and it's stored in the database. 3. the next time that user logs in, they hash their password with SHA256 instead of MD5 and avoid having to go through the process again. 4. at some point in the future, you disable logins for people with only MD5 hashed passwords (maybe). what we would need to make this work would be: a. a way to log in with MD5 until you can use VWRAP to carry the SHA256 password. b. a way to figure out which hashed password to send (MD5 or SHA256). in the case of second life, you probably COULD get away with using MD5 with the legacy protocol. i can't remember if the current legacy protocol supports maintenance caps. if it does you could use a maintenance cap. if not, you simply fail and wait for the user to call the support line. this would be pretty costly, but if we really want to avoid legacy in the new protocol, we're probably going to see a number of issues like this. if we had just enough legacy in the new protocol to support MD5, we could use the maintenance capability as described above. if we added a return value from the auth request that had the meaning of "unsupported algorithm" the client would know to retry the MD5 request with SHA256. just my $0.02. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 2:25 PM, Barry Leiba wrote: >> so if we simply said "we're going to ditch MD5 in favor of SHA256" >> there would be a problem with reverse compatibility of the >> authentication data. this is because you can't generate the pre-image >> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you >> can't do that in a way that insures that your MD5 pre image is the >> same as the password.) > > The usual way to handle this is with a migration process. =A0Credentials > are re-hashed with the new algorithm when they're changed, over time. > After a time, there's a cutoff and users are forced to change their > credentials the next time they log in. =A0The old login has to be > supported as long as there are users who have not yet changed... or > until someone decides to toss those users. > > Barry > From josh@lindenlab.com Tue Apr 6 15:05:16 2010 Return-Path: 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 BF1873A68A5 for ; Tue, 6 Apr 2010 15:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.625 X-Spam-Level: X-Spam-Status: No, score=0.625 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 RuYPZe-5Fa0V for ; Tue, 6 Apr 2010 15:05:16 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D0DB43A68A4 for ; Tue, 6 Apr 2010 15:05:15 -0700 (PDT) Received: by vws15 with SMTP id 15so190044vws.31 for ; Tue, 06 Apr 2010 15:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.78 with HTTP; Tue, 6 Apr 2010 15:05:10 -0700 (PDT) In-Reply-To: <20100406185739.GB6424@alinoe.com> References: <059.7033e411bbd74dc481125cfa915c0bb4@tools.ietf.org> <20100406185739.GB6424@alinoe.com> Date: Tue, 6 Apr 2010 15:05:10 -0700 Received: by 10.220.123.95 with SMTP id o31mr3941393vcr.23.1270591510689; Tue, 06 Apr 2010 15:05:10 -0700 (PDT) Message-ID: From: Joshua Bell To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636cd72e5a63842048398a3cd Subject: Re: [vwrap] #12: Event-like resource type for LLIDL X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:05:16 -0000 --001636cd72e5a63842048398a3cd Content-Type: text/plain; charset=UTF-8 On Tue, Apr 6, 2010 at 11:57 AM, Carlo Wood wrote: > I'm not sure if I follow what an "event" is. > The use cases that come to mind are where the authority itself is generating the event. In your scenario, the sim is simulating a rotating object, and is broadcasting the current angle to clients. Other examples are text chat and presence notifications from the sim. These don't fit into a RESTful model. SL clients also generate "events" that don't fit into a RESTful model, e.g. current gaze location, or (again) chat/presence. These *can* be transported over HTTP e.g. client->server as POST with minimal response, and server->client as a GET-based long poll (see draft-lentczner-vwrap-foundation-00 - which uses LLIDL!). But using HTTP in a non-RESTful way for this is an implementation details, and some have expressed desire to describe these "events" (and LLIDL as a whole) independent of the transport. --001636cd72e5a63842048398a3cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 6, 2010 at 11:57 AM, Carlo Wood <carlo@alinoe.com&= gt; wrote:
I'm not sure if I follow what an "event" is.
=

The use cases that come to mind are where the authority= itself is generating the event. In your scenario, the sim is simulating a = rotating object, and is broadcasting the current angle to clients. Other ex= amples are text chat and presence notifications from the sim. These don'= ;t fit into a RESTful model.

SL clients also generate "events" that don= 9;t fit into a RESTful model, e.g. current gaze location, or (again) chat/p= resence.

These *can* be transported over HTTP e.g.= client->server as POST with minimal response, and server->client as = a GET-based long poll (see=C2=A0draft-lentczner-vwrap-foundation-00 - which= uses LLIDL!). But using HTTP in a non-RESTful way for this is an implement= ation details, and some have expressed desire to describe these "event= s" (and LLIDL as a whole) independent of the transport.=C2=A0

--001636cd72e5a63842048398a3cd-- From ohmeadhbh@gmail.com Tue Apr 6 15:11:32 2010 Return-Path: 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 395933A69AA for ; Tue, 6 Apr 2010 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 c95FKGpOud1K for ; Tue, 6 Apr 2010 15:11:30 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 764043A6933 for ; Tue, 6 Apr 2010 15:11:30 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so136774qwb.31 for ; Tue, 06 Apr 2010 15:11:25 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=3bJVDGP5D705YORCwCFN3ur5NQA/UwVnH46r7G7U2rA=; b=mUIg/a/JaMvg4hEiu6YsjQrbHmcF+omwxxsCjU8xZI10g2kgLXgxaaeBFn8xTU2Z0Z fhQHGXBbkYQt6jeDBJZWduiaE+JEQt2KtCOL+CZWLyYgPMCsNzt3Rbqy3pXUSt1b8ilw eeomHSlwiwQdhxDHV2BdwcdtpiG+M4swgS2YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vKy5uShc5UvZ1z1MP3MoIT0PsT+v4rCzdBUkQnlB6jhJ1sPQlnjJ+zmHYN4apXq/6V wCUkG4QGsXAoWBDICXKIdzqg2n+XXbUb0qyZy1xqyXVimY3aiTwihMkNCMQQoqDfyclD uoD5bLAGECJ2lXbFamG2FB6/zGzQ59xWGUiSw= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 15:11:04 -0700 (PDT) In-Reply-To: References: <4BBB7705.4060206@stpeter.im> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 15:11:04 -0700 Received: by 10.229.88.193 with SMTP id b1mr4821455qcm.27.1270591885228; Tue, 06 Apr 2010 15:11:25 -0700 (PDT) Message-ID: To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:11:32 -0000 but ultimately, the question is, "how much legacy are we willing to support?" i don't think it was answered here, and i think we really should make some attempt to address it. the OpenSim grids and SL use radically similar protocols to do auth now. if we decided we didn't want to define a protocol with enough legacy to handle the MD5 based auth, then LL would likely use a technique that was proprietary. sure, the OpenSim people would reverse engineer it (i mean, after all, the viewer source is GPL licensed and pushed out the door with sufficient regularity.) or we could simply define reverse compatibility as part of the standard and allow deployers to start the migration on their time frame. removing MD5 auth from the spec is a bad idea because it forces people to deploy proprietary mechanisms to bring their systems in line with VWRAP when they COULD just as easily do the same thing with an open spec. what is definitely a good idea is to add the text "MD5 is provided for reverse compatibility and should not be used for new implementations" if it's not there already. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 2:25 PM, Barry Leiba wrote: >> so if we simply said "we're going to ditch MD5 in favor of SHA256" >> there would be a problem with reverse compatibility of the >> authentication data. this is because you can't generate the pre-image >> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you >> can't do that in a way that insures that your MD5 pre image is the >> same as the password.) > > The usual way to handle this is with a migration process. =A0Credentials > are re-hashed with the new algorithm when they're changed, over time. > After a time, there's a cutoff and users are forced to change their > credentials the next time they log in. =A0The old login has to be > supported as long as there are users who have not yet changed... or > until someone decides to toss those users. > > Barry > From djshag@hotmail.com Tue Apr 6 16:18:47 2010 Return-Path: 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 EE6853A68AE for ; Tue, 6 Apr 2010 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, STOX_REPLY_TYPE=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 61vmkJNF058i for ; Tue, 6 Apr 2010 16:18:45 -0700 (PDT) Received: from bay0-omc2-s20.bay0.hotmail.com (bay0-omc2-s20.bay0.hotmail.com [65.54.190.95]) by core3.amsl.com (Postfix) with ESMTP id 940CF3A67E1 for ; Tue, 6 Apr 2010 16:18:45 -0700 (PDT) Received: from BAY136-DS4 ([65.54.190.125]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 16:18:43 -0700 X-Originating-IP: [74.57.140.246] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: "Meadhbh Hamrick" References: <4BBB7705.4060206@stpeter.im> In-Reply-To: Date: Tue, 6 Apr 2010 19:18:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-OriginalArrivalTime: 06 Apr 2010 23:18:43.0410 (UTC) FILETIME=[7FEC5B20:01CAD5DF] Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:18:47 -0000 I think if someday LL ask me to change my password because they made their security system better i would really not mind. So typing a password take 1 minute for changing it. Same for all opensim grid if they someday ask me to change my password because they enforced security i'd be more than happy to provide them with a new one. I don't think people will leave SL just because you "forced" them to change a password honestly. -------------------------------------------------- From: "Meadhbh Hamrick" Sent: Tuesday, April 06, 2010 2:22 PM To: "Peter Saint-Andre" Cc: Subject: Re: [vwrap] authentication : remove reference to MD5 > we need clarification about how much of the second life legacy > protocol will be used in VWRAP. > > for instance. second life stores the MD5 hash of user passwords in the > user database and uses it to authenticate users when logging in. > > but MD5 has some significant problems which were exacerbated several > years ago when there was a security breach of linden's servers. > > so if we simply said "we're going to ditch MD5 in favor of SHA256" > there would be a problem with reverse compatibility of the > authentication data. this is because you can't generate the pre-image > from an MD5 MIC and then use it to generate a SHA256 MIC. (or you > can't do that in a way that insures that your MD5 pre image is the > same as the password.) > > so in other words, there is an action we could take in this group that > COULD make it very difficult for linden and presumably existing > OpenSim instances to use the authentication protocol. > > so the question is, to which degree do we add an engineering burden to > existing implementations that would like to adopt this group's output? > the question of the two string identifier is a good one. linden could > probably make systems that adhere to all sorts of different changes. > but to what degree to we make it easy for existing implementers vs. > the desires of people who have yet to build and implementation? > > -cheers > -meadhbh > > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre > wrote: >> On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: >>> okay. >>> >>> if we're going to remove VWRAP from all current implementations, >> >> What does that mean? I thought we were trying to build VWRAP into >> implementations, not rip it out. :) >> >>> i >>> vote we remove MD5 from the auth spec and replace it with a MIC with >>> better security properties, like SHA224 or SHA256. >> >> +1 to more secure authentication. >> >> My quick reading of the authentication draft led me to think that it >> needed a thorough review, but unfortunately I haven't had time to do >> that yet. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> >> _______________________________________________ >> 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 > From ohmeadhbh@gmail.com Tue Apr 6 20:35:21 2010 Return-Path: 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 8F6533A6928 for ; Tue, 6 Apr 2010 20:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 UH3keKvJSgh3 for ; Tue, 6 Apr 2010 20:35:20 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id E8C0B3A67EC for ; Tue, 6 Apr 2010 20:35:19 -0700 (PDT) Received: by qyk11 with SMTP id 11so640746qyk.13 for ; Tue, 06 Apr 2010 20:35:13 -0700 (PDT) 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 :from:date:received:message-id:subject:to:cc:content-type; bh=FfEM44D6pnaMCRLGlKfolE5G51aixK5GxRlOf8wr2FI=; b=vVk/zd0yIaPjdQ1rYJiv0MIyVXoljgrop7wWcSx2019Ajj9aiC0GIGOD0YZht7XhCe 4+cdYM4Uwp155IehCn4I55N6dm7ttbs71zHofL5h0e1oBsBHWnPTNX4D250bc9W3ib+v YTo0DMnM22Z7JIiMRmhTRB1qSM06FU9yLVRfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=E2y0UaLsgIbhrjcBf9A7AbHHAvpux52bAbLq34uQCfPd0SObSlNDMTWqaNHnrvjbCN 1EMKmB0D7Lw83E2w3vrHSYrOo84z5kTbWsqkhl6LWUHe54tOY+E6f3uHYGvpiK7hZ/vT KPZOTy0qOMaKgwwU2/Hzl8sPDWTWt8SGhZF4s= MIME-Version: 1.0 Received: by 10.229.247.72 with HTTP; Tue, 6 Apr 2010 20:34:53 -0700 (PDT) In-Reply-To: References: <4BBB7705.4060206@stpeter.im> From: Meadhbh Hamrick Date: Tue, 6 Apr 2010 20:34:53 -0700 Received: by 10.229.223.140 with SMTP id ik12mr2482899qcb.98.1270611313245; Tue, 06 Apr 2010 20:35:13 -0700 (PDT) Message-ID: To: Patnad Babii Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 03:35:21 -0000 actually. that does bring up a good point. LL _could_ just invalidate everyone's password and make them go through password reset. i agree, patnad, i would do it too, but it may be difficult to convince everyone to do it, and i'm not sure it's the kind of thing a standards organization should require of one of it's implementers. just my $0.02, but yeah, i'll let the lindens speak for themselves. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 6, 2010 at 4:18 PM, Patnad Babii wrote: > I think if someday LL ask me to change my password because they made their > security system better i would really not mind. So typing a password take 1 > minute for changing it. > > Same for all opensim grid if they someday ask me to change my password > because they enforced security i'd be more than happy to provide them with a > new one. > > I don't think people will leave SL just because you "forced" them to change > a password honestly. > > -------------------------------------------------- > From: "Meadhbh Hamrick" > Sent: Tuesday, April 06, 2010 2:22 PM > To: "Peter Saint-Andre" > Cc: > Subject: Re: [vwrap] authentication : remove reference to MD5 > >> we need clarification about how much of the second life legacy >> protocol will be used in VWRAP. >> >> for instance. second life stores the MD5 hash of user passwords in the >> user database and uses it to authenticate users when logging in. >> >> but MD5 has some significant problems which were exacerbated several >> years ago when there was a security breach of linden's servers. >> >> so if we simply said "we're going to ditch MD5 in favor of SHA256" >> there would be a problem with reverse compatibility of the >> authentication data. this is because you can't generate the pre-image >> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you >> can't do that in a way that insures that your MD5 pre image is the >> same as the password.) >> >> so in other words, there is an action we could take in this group that >> COULD make it very difficult for linden and presumably existing >> OpenSim instances to use the authentication protocol. >> >> so the question is, to which degree do we add an engineering burden to >> existing implementations that would like to adopt this group's output? >> the question of the two string identifier is a good one. linden could >> probably make systems that adhere to all sorts of different changes. >> but to what degree to we make it easy for existing implementers vs. >> the desires of people who have yet to build and implementation? >> >> -cheers >> -meadhbh >> >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre >> wrote: >>> >>> On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: >>>> >>>> okay. >>>> >>>> if we're going to remove VWRAP from all current implementations, >>> >>> What does that mean? I thought we were trying to build VWRAP into >>> implementations, not rip it out. :) >>> >>>> i >>>> vote we remove MD5 from the auth spec and replace it with a MIC with >>>> better security properties, like SHA224 or SHA256. >>> >>> +1 to more secure authentication. >>> >>> My quick reading of the authentication draft led me to think that it >>> needed a thorough review, but unfortunately I haven't had time to do >>> that yet. >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From morgaine.dinova@googlemail.com Tue Apr 6 22:29:36 2010 Return-Path: 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 5BEFD3A6877 for ; Tue, 6 Apr 2010 22:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5m37eh5hC+gF for ; Tue, 6 Apr 2010 22:29:35 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 417713A6862 for ; Tue, 6 Apr 2010 22:29:33 -0700 (PDT) Received: by ewy24 with SMTP id 24so338376ewy.13 for ; Tue, 06 Apr 2010 22:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=IZjHaGTFMcep14FzbMtL3DpM+qjCCJWlOD4S/+P0Hqw=; b=H11lYi9tDFHVqx8bze62JFjaRnF8dLEweCPcXBKowjpz3PwC4QlqLZaUC3ul845Fbp OrDfStSKwMYy2wV8MLEW7ERHR7FM4ctS1R3kFB4uXUcetrVswrJBHHiiwHqV7FZuxDpH EGj3yTUg28NbsJ0HxJ2GPufLZObdChLBZC51U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=l1o58LbZgIi1QPn6G/fxOD6YbGWJ+46Oqmt4nJadpcfIGKQlvVInTcffc3ik/2DOS0 EOC5dEtF0LOuW2CY4xJfK2Fwmnw9Fr24CDt9kMqkN17E6Z4M8NcPjBqs66r8Mz7+IkEF ZKLOTgij2yI7HoW1tzRjITjcAZr2FMggJI8bM= MIME-Version: 1.0 Received: by 10.213.105.66 with HTTP; Tue, 6 Apr 2010 22:29:26 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> <4BBB4D6E.60600@gmail.com> Date: Wed, 7 Apr 2010 06:29:26 +0100 Received: by 10.213.15.17 with SMTP id i17mr5096753eba.62.1270618166896; Tue, 06 Apr 2010 22:29:26 -0700 (PDT) Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0015174c37927ba98704839ed8f5 Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:29:36 -0000 --0015174c37927ba98704839ed8f5 Content-Type: text/plain; charset=ISO-8859-1 Thanks for confirming that, Joshua! The nature of the agent field is a small thing, but progress has been made. :-) Morgaine. ====================================== On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell wrote: > Speaking for Linden: > > (1) For the purposes of VWRAP interop, it is acceptable to us to assume > that a human readable agent identifier ("name") for Second Life can be > coerced to and from a single string field. Today, SL firstname/lastname > pairs are constrained to a subset of ASCII that disallows characters such as > periods and spaces. Therefore, as has been mentioned, it is possible today > to unambiguously encode an SL name as (firstname + "." + lastname) or > (firstname + " " + lastname). > > (2) As mentioned at > https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead and > at > https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up Linden > is investigating modifications to "names" in SL. However, it is too early to > comment on any details at this time. > > (3) That said, the investigative work for (2) is being done with the > benefits of (1) held firmly in mind. (As with practically anything in the > biz, this statement is not a contract or guarantee.) > > Therefore, from Linden's perspective, we can live with the proposed > simplified requirements of a single string. If it becomes necessary to > revisit that in the future we'll raise it. > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --0015174c37927ba98704839ed8f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for confirming that, Joshua!

The nature of the agent field is= a small thing, but progress has been made. :-)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell <josh@lindenlab.com> wrote:
=
Speaking for Linden:

(1) For the purposes of = VWRAP interop, it is acceptable to us to assume that a human readable agent= identifier ("name") for Second Life can be coerced to and from a= single string field. Today, SL firstname/lastname pairs are constrained to= a subset of ASCII that disallows characters such as periods and spaces. Th= erefore, as has been mentioned, it is possible today to unambiguously encod= e an SL name as (firstname + "." + lastname) or (firstname + &quo= t; " + lastname).


(3) That said, the investigative work for (2) is being = done with the benefits of (1) held firmly in mind. (As with practically any= thing in the biz, this statement is not a contract or guarantee.)

Therefore, from Linden's perspective, we can live w= ith the proposed simplified requirements of a single string. If it becomes = necessary to revisit that in the future we'll raise it.


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--0015174c37927ba98704839ed8f5-- From TammyNowotny@mac.com Wed Apr 7 03:10:31 2010 Return-Path: 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 B5C6E3A69FF for ; Wed, 7 Apr 2010 03:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1BVk6M8h07FX for ; Wed, 7 Apr 2010 03:10:30 -0700 (PDT) Received: from mail124c26.carrierzone.com (mail124c26.carrierzone.com [64.29.152.134]) by core3.amsl.com (Postfix) with ESMTP id CD5DD3A68C7 for ; Wed, 7 Apr 2010 03:10:29 -0700 (PDT) X-Authenticated-User: timothyhorrigan.myfairpoint.net Received: from [192.168.1.47] (pool-70-16-215-68.man.east.myfairpoint.net [70.16.215.68]) (authenticated bits=0) by mail124c26.carrierzone.com (8.13.6/8.13.1) with ESMTP id o37AAHnH005574; Wed, 7 Apr 2010 10:10:24 GMT Message-ID: <4BBC5A09.4040406@mac.com> Date: Wed, 07 Apr 2010 06:10:17 -0400 From: Tammy Nowotny User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Morgaine References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com> <4BBB45FA.8050408@gmail.com> <4BBB4D6E.60600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:10:32 -0000 Names are a small thing but they are immensely complicated (and important.) Morgaine wrote: > Thanks for confirming that, Joshua! > > The nature of the agent field is a small thing, but progress has been > made. :-) > > > Morgaine. > > > > > > ====================================== > > On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell > wrote: > > Speaking for Linden: > > (1) For the purposes of VWRAP interop, it is acceptable to us to > assume that a human readable agent identifier ("name") for Second > Life can be coerced to and from a single string field. Today, SL > firstname/lastname pairs are constrained to a subset of ASCII that > disallows characters such as periods and spaces. Therefore, as has > been mentioned, it is possible today to unambiguously encode an SL > name as (firstname + "." + lastname) or (firstname + " " + lastname). > > (2) As mentioned > at https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead and > at https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up Linden > is investigating modifications to "names" in SL. However, it is > too early to comment on any details at this time. > > (3) That said, the investigative work for (2) is being done with > the benefits of (1) held firmly in mind. (As with practically > anything in the biz, this statement is not a contract or guarantee.) > > Therefore, from Linden's perspective, we can live with the > proposed simplified requirements of a single string. If it becomes > necessary to revisit that in the future we'll raise it. > > > _______________________________________________ > 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 > From dyerbrookme@juno.com Wed Apr 7 09:44:24 2010 Return-Path: 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 B671B3A6940 for ; Wed, 7 Apr 2010 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 72HYRJpHuqzn for ; Wed, 7 Apr 2010 09:44:23 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id EAD403A67F6 for ; Wed, 7 Apr 2010 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1270658655; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=IhlohwGKNQXFG/wFTWhxQfwqseDPq5CKJBdsOaq73niewqDBrkZSqvu5v/7YuQZWy cZ/nl3RFk+z7DaudGxoFP3RfKpn5a+E9KYfM8Gjpd8KLgEIIG0CAmFyAyd4tvYSaKC MNpBxbcHWSwZsHQ4iAKJp7OLCzuJAQNsSs28Ikd8= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail08.vgs.untd.com [10.181.12.148]) by smtpout06.vgs.untd.com with SMTP id AABF53PTQAB2STBS for (sender ); Wed, 7 Apr 2010 09:43:26 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucRSgx0ktnep3CWmC3KUA1K8X1omANKT9nA== Received: (from dyerbrookme@juno.com) by webmail08.vgs.untd.com (jqueuemail) id QAW9JL38; Wed, 07 Apr 2010 09:43:24 PDT Received: from [173.77.185.208] by webmail08.vgs.untd.com with HTTP: Wed, 7 Apr 2010 16:43:10 GMT X-Originating-IP: [173.77.185.208] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 7 Apr 2010 16:43:10 GMT To: TammyNowotny@mac.com X-Mailer: Webmail Version 4.0 Message-Id: <20100407.124310.8383.0@webmail08.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-UNTD-BodySize: 6401 X-ContentStamp: 31:15:631465289 X-MAIL-INFO: 0e241dd11da5d1f914f4ddd1d4d4490ca9354d31f4394530c1c120c18995956495b091e4c1f9a1f9d5dda1348401f9f91d84b984997d196949f0040d4904404061b1b1f401296081e441e0e43029c005ede0c929c07490bdc1bdd92d0cf069bd21208564742100450ccd4081450db120f52581f4118954515015d930a1501db41de5b5e199b510ddd11d X-UNTD-Peer-Info: 10.181.12.148|webmail08.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:44:24 -0000 A reminder that all of you are deciding highly personal -- and public --= - matters like how names will be used and connected, how geographically = contiguous space or location will be represented and accessed, and how c= ontent will be moved and rights preserved *without the general public* a= nd *without a democratic process* to act as a curb on your own selfish i= nterests, which are largely of the copyleftist and even Stallmanite scho= ol at the extreme. = When we see the sheer insane unreason on the opensource dev list regardi= ng the TPV from some of the people now migrating here to continue the sa= me extremity, we have to wonder what's "up". Your flogging of these issues at the IETF is also suspect, given their u= ndemocratic procedures, their "humming" and the "tyranny of who shows up= *. As they say: I saw what you did there. Questions of naming, identity, space, connection, property, inventory, r= ights -- these are all human and social and people in the real world spe= nt centuries fashioning laws and policies over them, often going to war = of them. = You imagine that a handful of you superior and arrogant geeks can decide= these things for the Metaverse among yourselves, with no due process or= elections, and with no representation of those most interested -- the u= sers who pay for these servers and your salaries. You are trying to grab these issues without public participation merely = because they are complex and technical so that you can hide behind "tech= nology". But they aren't so complex that you can't explain them and thei= r ramifications normally in laymen's terms, as this is done all the time= when tekkies have to face civilian oversight. = We see from the court defeat of Net Neutrality that the Google-run campa= ign flogged by the EFF and ACLU gulling the public with fake terms imply= ing freedom of expression when it's about consumption and Google's loss-= leader to view Youtube liberated content for free in the consumer's last= mile, that checks and balances and reason prevail. And whatever you thi= nk you're getting away with now in hijacking the virtual world architect= ure discussion, you'll be stopped down the road with more government Int= ernet regulation and you'll have only yourselves to blame. = Even a little more democracy and a modicum of transparency could foresta= ll this inevitability, if you were more fair, and didn't pretend that an= obscure but technically accessible list like this is "transparency" and= that an IETF workshop run by big companies is "participation". If you want credibility, Joshua Linden, regarding Linden Lab's true inte= ntions with our virtual lives and stuff, and if you want to stem rumours= that you were forced to leave due to your opensource extremism, Infinit= y ex-Linden, then you should do a post on the general Linden blog explai= ning in laymen's terms *just what the hell you are doing with the world = and content which we created and paid for under the old mantra of 'Your = World, Your Imagination' when you make it easier to pipe it to OpenSim, = which is already rampant with content theft. If you are giving away the store -- and I see that you are -- then you o= we it to the public to be honest about it and not slip it in as a techni= cality. There are policies on Third Party Viewers at long last that put some cur= b on the script kiddies and opensource fanatics that compromise property= , privacy, and peace in Second Life due to TPV ripping, exposure, and gr= iefing. Is there going to be an interop policy for Lindens and ex-Lindens and th= e big companies like IBM represented by Zha Ewry and Dale Innis, and Int= el, represented by John Hurliman, the first maker and seller of copybot = in Second Life? Prokofy Neva ---------- Original Message ---------- From: Tammy Nowotny To: Morgaine Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? Date: Wed, 07 Apr 2010 06:10:17 -0400 Names are a small thing but they are immensely complicated (and importan= t.) Morgaine wrote: > Thanks for confirming that, Joshua! > > The nature of the agent field is a small thing, but progress has been = = > made. :-) > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell > wrote: > > Speaking for Linden: > > (1) For the purposes of VWRAP interop, it is acceptable to us to > assume that a human readable agent identifier ("name") for Second > Life can be coerced to and from a single string field. Today, SL > firstname/lastname pairs are constrained to a subset of ASCII that= > disallows characters such as periods and spaces. Therefore, as has= > been mentioned, it is possible today to unambiguously encode an SL= > name as (firstname + "." + lastname) or (firstname + " " + lastnam= e). > > (2) As mentioned > at https://blogs.secondlife.com/community/features/blog/2010/01/03= /happy-new-year-looking-backlooking-ahead and > at https://blogs.secondlife.com/community/features/blog/2010/01/22= /will-the-real-you-please-stand-up Linden > is investigating modifications to "names" in SL. However, it is > too early to comment on any details at this time. = > > (3) That said, the investigative work for (2) is being done with > the benefits of (1) held firmly in mind. (As with practically > anything in the biz, this statement is not a contract or guarantee= .) > > Therefore, from Linden's perspective, we can live with the > proposed simplified requirements of a single string. If it becomes= > necessary to revisit that in the future we'll raise it. > > > _______________________________________________ > 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 > = _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.juno.com/freeemail?refcd=3DJUTAGOUT1FREM0210 From sean@uci.edu Wed Apr 7 09:59:03 2010 Return-Path: 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 586093A69A5 for ; Wed, 7 Apr 2010 09:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 E61tU01tfDPI for ; Wed, 7 Apr 2010 09:59:02 -0700 (PDT) Received: from smtp2.es.uci.edu (smtp2.es.uci.edu [128.200.80.28]) by core3.amsl.com (Postfix) with ESMTP id CA38928C12E for ; Wed, 7 Apr 2010 09:58:58 -0700 (PDT) Received: from [128.200.62.123] (sean.nac.uci.edu [128.200.62.123]) (authenticated bits=0) by smtp2.es.uci.edu (8.13.1/8.13.1) with ESMTP id o37Gwslp032381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Apr 2010 09:58:55 -0700 X-UCInetID: sean Message-ID: <4BBCB9CB.1000608@uci.edu> Date: Wed, 07 Apr 2010 09:58:51 -0700 From: Sean Hennessee Organization: NACS CCS User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Meadhbh Hamrick References: <4BBB7705.4060206@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] authentication : remove reference to MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:59:03 -0000 If VWRAP has no legacy support, can't the implementors still have mixed mode support as long as they decide to? Just because an implementor supports VWRAP, (with no legacy support), doesn't necessarily mean they can't support legacy protocols as well. Eventually one would hope all would transition to only VWRAP, but implementors are really the determining factor of how long that transition takes. Even many web browsers continue to support old versions of the HTML spec while still supporting newer versions. Perhaps VWRAP should include a protocol negotiation protocol allowing services to determine what protocols and versions of protocols are supported on each end. "Sorry, your client is not supported on this sim" should be an option. I see (saw) it often when connecting to SL after major client/server updates. Peace, Sean Meadhbh Hamrick wrote: > actually. that does bring up a good point. LL _could_ just invalidate > everyone's password and make them go through password reset. > > i agree, patnad, i would do it too, but it may be difficult to > convince everyone to do it, and i'm not sure it's the kind of thing a > standards organization should require of one of it's implementers. > > just my $0.02, but yeah, i'll let the lindens speak for themselves. > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Apr 6, 2010 at 4:18 PM, Patnad Babii wrote: >> I think if someday LL ask me to change my password because they made their >> security system better i would really not mind. So typing a password take 1 >> minute for changing it. >> >> Same for all opensim grid if they someday ask me to change my password >> because they enforced security i'd be more than happy to provide them with a >> new one. >> >> I don't think people will leave SL just because you "forced" them to change >> a password honestly. >> >> -------------------------------------------------- >> From: "Meadhbh Hamrick" >> Sent: Tuesday, April 06, 2010 2:22 PM >> To: "Peter Saint-Andre" >> Cc: >> Subject: Re: [vwrap] authentication : remove reference to MD5 >> >>> we need clarification about how much of the second life legacy >>> protocol will be used in VWRAP. >>> >>> for instance. second life stores the MD5 hash of user passwords in the >>> user database and uses it to authenticate users when logging in. >>> >>> but MD5 has some significant problems which were exacerbated several >>> years ago when there was a security breach of linden's servers. >>> >>> so if we simply said "we're going to ditch MD5 in favor of SHA256" >>> there would be a problem with reverse compatibility of the >>> authentication data. this is because you can't generate the pre-image >>> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you >>> can't do that in a way that insures that your MD5 pre image is the >>> same as the password.) >>> >>> so in other words, there is an action we could take in this group that >>> COULD make it very difficult for linden and presumably existing >>> OpenSim instances to use the authentication protocol. >>> >>> so the question is, to which degree do we add an engineering burden to >>> existing implementations that would like to adopt this group's output? >>> the question of the two string identifier is a good one. linden could >>> probably make systems that adhere to all sorts of different changes. >>> but to what degree to we make it easy for existing implementers vs. >>> the desires of people who have yet to build and implementation? >>> >>> -cheers >>> -meadhbh >>> >>> >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre >>> wrote: >>>> On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: >>>>> okay. >>>>> >>>>> if we're going to remove VWRAP from all current implementations, >>>> What does that mean? I thought we were trying to build VWRAP into >>>> implementations, not rip it out. :) >>>> >>>>> i >>>>> vote we remove MD5 from the auth spec and replace it with a MIC with >>>>> better security properties, like SHA224 or SHA256. >>>> +1 to more secure authentication. >>>> >>>> My quick reading of the authentication draft led me to think that it >>>> needed a thorough review, but unfortunately I haven't had time to do >>>> that yet. >>>> >>>> Peter >>>> >>>> -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ -- Sean Hennessee Central Computing Support Office of Information Technology UC Irvine ... . .- -. / .... . -. -. . ... ... . . From djshag@hotmail.com Wed Apr 7 16:17:45 2010 Return-Path: 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 3C84D3A67B2 for ; Wed, 7 Apr 2010 16:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, STOX_REPLY_TYPE=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 d09z8aPh4aBN for ; Wed, 7 Apr 2010 16:17:41 -0700 (PDT) Received: from bay0-omc2-s14.bay0.hotmail.com (bay0-omc2-s14.bay0.hotmail.com [65.54.190.89]) by core3.amsl.com (Postfix) with ESMTP id 54E7E3A659A for ; Wed, 7 Apr 2010 16:17:41 -0700 (PDT) Received: from BAY136-DS10 ([65.54.190.125]) by bay0-omc2-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 16:17:39 -0700 X-Originating-IP: [74.57.140.246] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: References: <20100407.124310.8383.0@webmail08.vgs.untd.com> In-Reply-To: <20100407.124310.8383.0@webmail08.vgs.untd.com> Date: Wed, 7 Apr 2010 19:17:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-OriginalArrivalTime: 07 Apr 2010 23:17:39.0136 (UTC) FILETIME=[8406AC00:01CAD6A8] Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 23:17:45 -0000 look prokofy. the people in this list aren't arrogant geek as you may think. The people here are people from everywhere in the world and it can be everyone as it is an open (on the internet) mailing list. So i don't know why you keep trolling about *US* deciding for the mass. If the mass have interest in the VWRAP well they are free to express them self right here no one will be rejected. So please stop profaning your insanity THAT doesn't have a place here. We (everyone in this list) are trying to establish a protocol to make virtual world server communicate together, where LL can resign at anytime they see fit if they think it is not something "SECURE" for their users or any other maters. So far I see a bunch of very honest people who are trying to do (with the help of IBM and INTEL BTW.. ) the best protocol possible with their knowledge and the IETF knowledge as well which is the best entity of people on the internet to help develop such protocol. -------------------------------------------------- From: Sent: Wednesday, April 07, 2010 12:43 PM To: Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? > A reminder that all of you are deciding highly personal -- and public --- > matters like how names will be used and connected, how geographically > contiguous space or location will be represented and accessed, and how > content will be moved and rights preserved *without the general public* > and *without a democratic process* to act as a curb on your own selfish > interests, which are largely of the copyleftist and even Stallmanite > school at the extreme. > > When we see the sheer insane unreason on the opensource dev list regarding > the TPV from some of the people now migrating here to continue the same > extremity, we have to wonder what's "up". > > Your flogging of these issues at the IETF is also suspect, given their > undemocratic procedures, their "humming" and the "tyranny of who shows > up*. > > As they say: I saw what you did there. > > Questions of naming, identity, space, connection, property, inventory, > rights -- these are all human and social and people in the real world > spent centuries fashioning laws and policies over them, often going to war > of them. > > You imagine that a handful of you superior and arrogant geeks can decide > these things for the Metaverse among yourselves, with no due process or > elections, and with no representation of those most interested -- the > users who pay for these servers and your salaries. > > You are trying to grab these issues without public participation merely > because they are complex and technical so that you can hide behind > "technology". But they aren't so complex that you can't explain them and > their ramifications normally in laymen's terms, as this is done all the > time when tekkies have to face civilian oversight. > > We see from the court defeat of Net Neutrality that the Google-run > campaign flogged by the EFF and ACLU gulling the public with fake terms > implying freedom of expression when it's about consumption and Google's > loss-leader to view Youtube liberated content for free in the consumer's > last mile, that checks and balances and reason prevail. And whatever you > think you're getting away with now in hijacking the virtual world > architecture discussion, you'll be stopped down the road with more > government Internet regulation and you'll have only yourselves to blame. > > Even a little more democracy and a modicum of transparency could forestall > this inevitability, if you were more fair, and didn't pretend that an > obscure but technically accessible list like this is "transparency" and > that an IETF workshop run by big companies is "participation". > > If you want credibility, Joshua Linden, regarding Linden Lab's true > intentions with our virtual lives and stuff, and if you want to stem > rumours that you were forced to leave due to your opensource extremism, > Infinity ex-Linden, then you should do a post on the general Linden blog > explaining in laymen's terms *just what the hell you are doing with the > world and content which we created and paid for under the old mantra of > 'Your World, Your Imagination' when you make it easier to pipe it to > OpenSim, which is already rampant with content theft. > > If you are giving away the store -- and I see that you are -- then you owe > it to the public to be honest about it and not slip it in as a > technicality. > > There are policies on Third Party Viewers at long last that put some curb > on the script kiddies and opensource fanatics that compromise property, > privacy, and peace in Second Life due to TPV ripping, exposure, and > griefing. > > Is there going to be an interop policy for Lindens and ex-Lindens and the > big companies like IBM represented by Zha Ewry and Dale Innis, and Intel, > represented by John Hurliman, the first maker and seller of copybot in > Second Life? > > Prokofy Neva > > ---------- Original Message ---------- > From: Tammy Nowotny > To: Morgaine > Cc: vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? > Date: Wed, 07 Apr 2010 06:10:17 -0400 > > Names are a small thing but they are immensely complicated (and > important.) > > Morgaine wrote: >> Thanks for confirming that, Joshua! >> >> The nature of the agent field is a small thing, but progress has been >> made. :-) >> >> >> Morgaine. >> >> >> >> >> >> ====================================== >> >> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell > > wrote: >> >> Speaking for Linden: >> >> (1) For the purposes of VWRAP interop, it is acceptable to us to >> assume that a human readable agent identifier ("name") for Second >> Life can be coerced to and from a single string field. Today, SL >> firstname/lastname pairs are constrained to a subset of ASCII that >> disallows characters such as periods and spaces. Therefore, as has >> been mentioned, it is possible today to unambiguously encode an SL >> name as (firstname + "." + lastname) or (firstname + " " + lastname). >> >> (2) As mentioned >> at >> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead >> and >> at >> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up >> Linden >> is investigating modifications to "names" in SL. However, it is >> too early to comment on any details at this time. >> >> (3) That said, the investigative work for (2) is being done with >> the benefits of (1) held firmly in mind. (As with practically >> anything in the biz, this statement is not a contract or guarantee.) >> >> Therefore, from Linden's perspective, we can live with the >> proposed simplified requirements of a single string. If it becomes >> necessary to revisit that in the future we'll raise it. >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > ____________________________________________________________ > Get Free Email with Video Mail & Video Chat! > http://www.juno.com/freeemail?refcd=JUTAGOUT1FREM0210 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dyerbrookme@juno.com Wed Apr 7 17:09:06 2010 Return-Path: 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 75BD63A6847 for ; Wed, 7 Apr 2010 17:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_LETTER=-2, UNPARSEABLE_RELAY=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 FYNTZUSWDYdj for ; Wed, 7 Apr 2010 17:09:04 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id E00413A6842 for ; Wed, 7 Apr 2010 17:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1270685335; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=RUDW9DupLG7y4IAZgcG5ni7tRmNc/W+BQu2HgBmX2MDSm87ELvV2xYdNu8yT1k/BC 6Aywu0FbnQ5naZ2+EtxjgLrCFrxC+ALiZsh/+Jub891aV48Mx83IwFbX8j4dwN/Seh wIapQZd7QYijt1cRmsKxDsgoy/FVRFSweyNVw7os= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail08.vgs.untd.com [10.181.12.148]) by smtpout04.vgs.untd.com with SMTP id AABF54HWSAQJC8C2 for (sender ); Wed, 7 Apr 2010 17:08:48 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucRSgx0ktnep3THmSlfB5ca//xM0yxUOT1w== Received: (from dyerbrookme@juno.com) by webmail08.vgs.untd.com (jqueuemail) id QAX2ZARN; Wed, 07 Apr 2010 17:08:20 PDT Received: from [173.77.185.208] by webmail08.vgs.untd.com with HTTP: Thu, 8 Apr 2010 00:07:44 GMT X-Originating-IP: [173.77.185.208] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 8 Apr 2010 00:07:44 GMT To: djshag@hotmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20100407.200744.23911.0@webmail08.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-UNTD-BodySize: 21193 X-ContentStamp: 151:75:2679912002 X-MAIL-INFO: 301cc56cc5ac6c0925d58c6cecec7caddc61dd71d559d9d8c1c198c1b58888218815e8bdc1095d09558c5de9192c0909c51979190d088d9d7ced05f57c059595bca8a8d52ce139d1bd00b8bdd8e19941f8b80ce199853c35c1353d11aded9d352898ac8c1ca10d55a155e90d55b179bc599168d5f8f1b5c17d3868916dc9c5b571c115b5891cb1a9f5599c6c78a111ec25788c0db1e5ac25ed556545d9f96991e949f9417d41c1bd00b8bdd8e19941 X-UNTD-Peer-Info: 10.181.12.148|webmail08.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 00:09:06 -0000 It's hardly "trolling" to state the truth of what is going on here: tech= nologists are deciding very gravely important issues for users, without = user imput simply because a) it is too technical b) it is too sprawling = and c) it is too hard to justify attention and education of oneself on t= he issues when it might merely be to discover that the fight was over us= ing....the IRC channel or Joombla. Sigh. *You're* trolling as you always do on the Concierge list every time I sp= eak up critically about the abusive Emerald devs and viewer and in suppo= rt of the Third Party Viewer policy (which Emerald has not signed). = The idea that "people from all over the world" involved in a...wonky obs= cure list on VWRP that even tekkies might find hard to follow qualifies = something as "open" and "free" is indicative of the very problem I'm ide= ntifying. And this very arrogant statement itself: "If the mass have interest in t= he VWRAP well they are free to express them self right here no one will = be rejected." -- and then telling me to shut up and not "troll" (!) let'= s us know how REALLY free it is. Tekkies project much when they invoke this discredited old early web and= Well notion of "trolling". In normal society, people asking persistent = questions of those in power and making pointed statements about their di= screpancies are called "citizens" not "trolls". LL may be able to resign anytime they think this project is not secure f= or its users, but hey, it's *Lindens* resigning who are *still on the pr= oject* (!) that lets us know that we are right to be concerned about sec= urity, given some of the extremity of their opensource zealotry, and giv= en the rumours that they resigned over the Third Party Viewer policy. Fu= rthermore, Lindens in conjunction with the most extreme of the crazies o= n the OS dev list, that even (remaining) Lindens have to now quell and p= ut down, on *this* list makes us wonder if we are dealing with dvoyevlas= tiye (dual power). Re: "So far I see a bunch of very honest people who are trying to do (wi= th the help of IBM and INTEL BTW.. ) the best protocol possible with the= ir knowledge and the IETF knowledge as well which is the best entity of = people on the internet to help develop such protocol. I don't have the touching faith in big IT companies that you do. I see t= hem only too happy to harvest the free labour of opensource zealots and = let a small company and its devotees to OS be the cat's paw for their la= rger agendas, as yet opaque. We all know they want to sell widgets. It's= good that they make and sell widgets because we use widgets. But if the= y are knocking down the "walled garden" to sell widgets that put money i= n their pockets and destroy our privacy and IP that we were using to mon= etarize the VWs, hey, we want to hear more about the plan here. That's why I'm calling on big companies and small, individuals and ex-Li= ndens, to start making coherent *public* and *understandable statements*= about *what you are doing here*. Transparency isn't saying belligerentl= y "anyone can join this open list" or "anyone can learn to code and patc= h or GTFO". = Real accountability with transparency is explaining in laymen's normal t= erms what the decisions are on this roadmap. How you are handling the co= ntroversies about permissions on objects. What the different schools of = thought are among yourselves. How you plan to protect IP. How you plan t= o enable those who wish to keep anonymity to keep it intact. How you pla= n to enable those who want their avatar name's associations to survive a= cross frontiers but without griefing. How you plan to preserve geographi= cal contiguous space not only as a metaphor but as a structure for comme= rce -- or whether you will use the excuse of interop to drive people to = big web stores like Xstreet. In short, it's a social demand for your acc= ountability, which you must display along with your technical expertise = in social media because it's social. All of these are good questions to be asking -- and answering. Prokofy ---------- Original Message ---------- From: "Patnad Babii" To: Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? Date: Wed, 7 Apr 2010 19:17:33 -0400 look prokofy. the people in this list aren't arrogant geek as you may th= ink. = The people here are people from everywhere in the world and it can be = everyone as it is an open (on the internet) mailing list. So i don't kno= w = why you keep trolling about *US* deciding for the mass. If the mass hav= e = interest in the VWRAP well they are free to express them self right here= no = one will be rejected. So please stop profaning your insanity THAT doesn't have a place here. = We = (everyone in this list) are trying to establish a protocol to make virtu= al = world server communicate together, where LL can resign at anytime they s= ee = fit if they think it is not something "SECURE" for their users or any ot= her = maters. So far I see a bunch of very honest people who are trying to do (with th= e = help of IBM and INTEL BTW.. ) the best protocol possible with their = knowledge and the IETF knowledge as well which is the best entity of peo= ple = on the internet to help develop such protocol. -------------------------------------------------- From: Sent: Wednesday, April 07, 2010 12:43 PM To: Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? > A reminder that all of you are deciding highly personal -- and public = --- = > matters like how names will be used and connected, how geographically = = > contiguous space or location will be represented and accessed, and how= = > content will be moved and rights preserved *without the general public= * = > and *without a democratic process* to act as a curb on your own selfis= h = > interests, which are largely of the copyleftist and even Stallmanite = > school at the extreme. > > When we see the sheer insane unreason on the opensource dev list regar= ding = > the TPV from some of the people now migrating here to continue the sam= e = > extremity, we have to wonder what's "up". > > Your flogging of these issues at the IETF is also suspect, given their= = > undemocratic procedures, their "humming" and the "tyranny of who shows= = > up*. > > As they say: I saw what you did there. > > Questions of naming, identity, space, connection, property, inventory,= = > rights -- these are all human and social and people in the real world = = > spent centuries fashioning laws and policies over them, often going to= war = > of them. > > You imagine that a handful of you superior and arrogant geeks can deci= de = > these things for the Metaverse among yourselves, with no due process o= r = > elections, and with no representation of those most interested -- the = = > users who pay for these servers and your salaries. > > You are trying to grab these issues without public participation merel= y = > because they are complex and technical so that you can hide behind = > "technology". But they aren't so complex that you can't explain them a= nd = > their ramifications normally in laymen's terms, as this is done all th= e = > time when tekkies have to face civilian oversight. > > We see from the court defeat of Net Neutrality that the Google-run = > campaign flogged by the EFF and ACLU gulling the public with fake term= s = > implying freedom of expression when it's about consumption and Google'= s = > loss-leader to view Youtube liberated content for free in the consumer= 's = > last mile, that checks and balances and reason prevail. And whatever y= ou = > think you're getting away with now in hijacking the virtual world = > architecture discussion, you'll be stopped down the road with more = > government Internet regulation and you'll have only yourselves to blam= e. > > Even a little more democracy and a modicum of transparency could fores= tall = > this inevitability, if you were more fair, and didn't pretend that an = = > obscure but technically accessible list like this is "transparency" an= d = > that an IETF workshop run by big companies is "participation". > > If you want credibility, Joshua Linden, regarding Linden Lab's true = > intentions with our virtual lives and stuff, and if you want to stem = > rumours that you were forced to leave due to your opensource extremism= , = > Infinity ex-Linden, then you should do a post on the general Linden bl= og = > explaining in laymen's terms *just what the hell you are doing with th= e = > world and content which we created and paid for under the old mantra o= f = > 'Your World, Your Imagination' when you make it easier to pipe it to = > OpenSim, which is already rampant with content theft. > > If you are giving away the store -- and I see that you are -- then you= owe = > it to the public to be honest about it and not slip it in as a = > technicality. > > There are policies on Third Party Viewers at long last that put some c= urb = > on the script kiddies and opensource fanatics that compromise property= , = > privacy, and peace in Second Life due to TPV ripping, exposure, and = > griefing. > > Is there going to be an interop policy for Lindens and ex-Lindens and = the = > big companies like IBM represented by Zha Ewry and Dale Innis, and Int= el, = > represented by John Hurliman, the first maker and seller of copybot in= = > Second Life? > > Prokofy Neva > > ---------- Original Message ---------- > From: Tammy Nowotny > To: Morgaine > Cc: vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? > Date: Wed, 07 Apr 2010 06:10:17 -0400 > > Names are a small thing but they are immensely complicated (and = > important.) > > Morgaine wrote: >> Thanks for confirming that, Joshua! >> >> The nature of the agent field is a small thing, but progress has been= >> made. :-) >> >> >> Morgaine. >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell > > wrote: >> >> Speaking for Linden: >> >> (1) For the purposes of VWRAP interop, it is acceptable to us to >> assume that a human readable agent identifier ("name") for Second= >> Life can be coerced to and from a single string field. Today, SL >> firstname/lastname pairs are constrained to a subset of ASCII tha= t >> disallows characters such as periods and spaces. Therefore, as ha= s >> been mentioned, it is possible today to unambiguously encode an S= L >> name as (firstname + "." + lastname) or (firstname + " " + lastna= me). >> >> (2) As mentioned >> at = >> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy= -new-year-looking-backlooking-ahead = >> and >> at = >> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-= the-real-you-please-stand-up = >> Linden >> is investigating modifications to "names" in SL. However, it is >> too early to comment on any details at this time. >> >> (3) That said, the investigative work for (2) is being done with >> the benefits of (1) held firmly in mind. (As with practically >> anything in the biz, this statement is not a contract or guarante= e.) >> >> Therefore, from Linden's perspective, we can live with the >> proposed simplified requirements of a single string. If it become= s >> necessary to revisit that in the future we'll raise it. >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > ____________________________________________________________ > Get Free Email with Video Mail & Video Chat! > http://www.juno.com/freeemail?refcd=3DJUTAGOUT1FREM0210 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > = ---------- Original Message ---------- From: "Patnad Babii" To: Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? Date: Wed, 7 Apr 2010 19:17:33 -0400 look prokofy. the people in this list aren't arrogant geek as you may th= ink. = The people here are people from everywhere in the world and it can be = everyone as it is an open (on the internet) mailing list. So i don't kno= w = why you keep trolling about *US* deciding for the mass. If the mass hav= e = interest in the VWRAP well they are free to express them self right here= no = one will be rejected. So please stop profaning your insanity THAT doesn't have a place here. = We = (everyone in this list) are trying to establish a protocol to make virtu= al = world server communicate together, where LL can resign at anytime they s= ee = fit if they think it is not something "SECURE" for their users or any ot= her = maters. So far I see a bunch of very honest people who are trying to do (with th= e = help of IBM and INTEL BTW.. ) the best protocol possible with their = knowledge and the IETF knowledge as well which is the best entity of peo= ple = on the internet to help develop such protocol. -------------------------------------------------- From: Sent: Wednesday, April 07, 2010 12:43 PM To: Cc: Subject: Re: [vwrap] Removing first name / last name assumptions? > A reminder that all of you are deciding highly personal -- and public = --- = > matters like how names will be used and connected, how geographically = = > contiguous space or location will be represented and accessed, and how= = > content will be moved and rights preserved *without the general public= * = > and *without a democratic process* to act as a curb on your own selfis= h = > interests, which are largely of the copyleftist and even Stallmanite = > school at the extreme. > > When we see the sheer insane unreason on the opensource dev list regar= ding = > the TPV from some of the people now migrating here to continue the sam= e = > extremity, we have to wonder what's "up". > > Your flogging of these issues at the IETF is also suspect, given their= = > undemocratic procedures, their "humming" and the "tyranny of who shows= = > up*. > > As they say: I saw what you did there. > > Questions of naming, identity, space, connection, property, inventory,= = > rights -- these are all human and social and people in the real world = = > spent centuries fashioning laws and policies over them, often going to= war = > of them. > > You imagine that a handful of you superior and arrogant geeks can deci= de = > these things for the Metaverse among yourselves, with no due process o= r = > elections, and with no representation of those most interested -- the = = > users who pay for these servers and your salaries. > > You are trying to grab these issues without public participation merel= y = > because they are complex and technical so that you can hide behind = > "technology". But they aren't so complex that you can't explain them a= nd = > their ramifications normally in laymen's terms, as this is done all th= e = > time when tekkies have to face civilian oversight. > > We see from the court defeat of Net Neutrality that the Google-run = > campaign flogged by the EFF and ACLU gulling the public with fake term= s = > implying freedom of expression when it's about consumption and Google'= s = > loss-leader to view Youtube liberated content for free in the consumer= 's = > last mile, that checks and balances and reason prevail. And whatever y= ou = > think you're getting away with now in hijacking the virtual world = > architecture discussion, you'll be stopped down the road with more = > government Internet regulation and you'll have only yourselves to blam= e. > > Even a little more democracy and a modicum of transparency could fores= tall = > this inevitability, if you were more fair, and didn't pretend that an = = > obscure but technically accessible list like this is "transparency" an= d = > that an IETF workshop run by big companies is "participation". > > If you want credibility, Joshua Linden, regarding Linden Lab's true = > intentions with our virtual lives and stuff, and if you want to stem = > rumours that you were forced to leave due to your opensource extremism= , = > Infinity ex-Linden, then you should do a post on the general Linden bl= og = > explaining in laymen's terms *just what the hell you are doing with th= e = > world and content which we created and paid for under the old mantra o= f = > 'Your World, Your Imagination' when you make it easier to pipe it to = > OpenSim, which is already rampant with content theft. > > If you are giving away the store -- and I see that you are -- then you= owe = > it to the public to be honest about it and not slip it in as a = > technicality. > > There are policies on Third Party Viewers at long last that put some c= urb = > on the script kiddies and opensource fanatics that compromise property= , = > privacy, and peace in Second Life due to TPV ripping, exposure, and = > griefing. > > Is there going to be an interop policy for Lindens and ex-Lindens and = the = > big companies like IBM represented by Zha Ewry and Dale Innis, and Int= el, = > represented by John Hurliman, the first maker and seller of copybot in= = > Second Life? > > Prokofy Neva > > ---------- Original Message ---------- > From: Tammy Nowotny > To: Morgaine > Cc: vwrap@ietf.org > Subject: Re: [vwrap] Removing first name / last name assumptions? > Date: Wed, 07 Apr 2010 06:10:17 -0400 > > Names are a small thing but they are immensely complicated (and = > important.) > > Morgaine wrote: >> Thanks for confirming that, Joshua! >> >> The nature of the agent field is a small thing, but progress has been= >> made. :-) >> >> >> Morgaine. >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell > > wrote: >> >> Speaking for Linden: >> >> (1) For the purposes of VWRAP interop, it is acceptable to us to >> assume that a human readable agent identifier ("name") for Second= >> Life can be coerced to and from a single string field. Today, SL >> firstname/lastname pairs are constrained to a subset of ASCII tha= t >> disallows characters such as periods and spaces. Therefore, as ha= s >> been mentioned, it is possible today to unambiguously encode an S= L >> name as (firstname + "." + lastname) or (firstname + " " + lastna= me). >> >> (2) As mentioned >> at = >> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy= -new-year-looking-backlooking-ahead = >> and >> at = >> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-= the-real-you-please-stand-up = >> Linden >> is investigating modifications to "names" in SL. However, it is >> too early to comment on any details at this time. >> >> (3) That said, the investigative work for (2) is being done with >> the benefits of (1) held firmly in mind. (As with practically >> anything in the biz, this statement is not a contract or guarante= e.) >> >> Therefore, from Linden's perspective, we can live with the >> proposed simplified requirements of a single string. If it become= s >> necessary to revisit that in the future we'll raise it. >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > ____________________________________________________________ > Get Free Email with Video Mail & Video Chat! > http://www.juno.com/freeemail?refcd=3DJUTAGOUT1FREM0210 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > = ____________________________________________________________ Penny Stock Jumping 2000% Sign up to the #1 voted penny stock newsletter for free today! http://thirdpartyoffers.juno.com/TGL3141/4bbd1e90d929f143e24st04vuc From john.hurliman@intel.com Thu Apr 8 10:14:16 2010 Return-Path: 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 C791F3A69A6 for ; Thu, 8 Apr 2010 10:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-2.900, BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] 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 ndY99UT092zc for ; Thu, 8 Apr 2010 10:14:11 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 473513A6839 for ; Thu, 8 Apr 2010 10:14:06 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 08 Apr 2010 10:13:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,171,1270450800"; d="scan'208";a="507493664" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 08 Apr 2010 10:13:56 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Apr 2010 11:13:45 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Thu, 8 Apr 2010 11:13:36 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Thu, 8 Apr 2010 11:13:31 -0600 Thread-Topic: VWRAP example client code Thread-Index: AcrXPtA1kDN3gliuQGGEdwi4PbPaqA== Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCB7AF0E8@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [vwrap] VWRAP example client code X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:14:16 -0000 I was trying out Unity3D last night to see if I could build a simple VWRAP = client. I don't have a full client working, but I did hack together a first= pass at the VWRAP login implementation. I'm posting the code here to get t= he ball rolling on the VWRAP teleport discussion and shine some light on a = few cloudy issues. Notes: * This code was designed assuming the launch document contains a pre-authen= ticated login URL. Pre-authenticated login URLs are actually kind of silly;= if you are going that route why not just embed the agent seed capability r= ight in the launch doc and skip draft-hamrick-vwrap-authentication entirely= . This sticks closer to the VWRAP drafts as published though. * Speaking of steps you can skip, the agent/session capability only seems r= elevant to platforms using LLUDP. This code is trying to get a websocket_ev= ent_queue capability which has the session token embedded in the websocket = URL, so there's no need for a session_id or secure_session_id. I included t= he code to fetch agent/session just to stick with what is currently publish= ed in OGP Teleport Draft 5, and in case I missed some obvious use case wher= e a separate session_id token is needed. * Unity3D makes heavy use of coroutines for things like fetching web resour= ces, and since coroutines are far from optimal in C# (supported at the comp= iler level instead of the runtime, no way to return values or use "out" par= ameters with coroutines) it uses closures to return values from PostLLSD() = and GetLLSD(). Apologies if the logic is difficult to follow there. * If you look closely you'll notice I just invented a seed capability forma= t. It is sending { "cap1": {}, "cap2": {} } and receiving { "cap1": {"uri"= : "..."}, "cap2": {"uri": "..."} }. I think this captures the spirit of the= "map of maps" concept that was discussed at IETF77, although nothing has b= een discussed for the specific format yet. John using UnityEngine; using System; using System.Collections; using System.Text; using OpenMetaverse; using OpenMetaverse.StructuredData; public class VWRAP : MonoBehaviour { public static bool TryParseLaunchDoc(string document, out Uri loginUri,= out Uri regionUri) { OSDMap launchDoc =3D OSDParser.Deserialize(document) as OSDMap; if (launchDoc !=3D null) { loginUri =3D launchDoc["loginuri"].AsUri(); regionUri =3D launchDoc["region"].AsUri(); } else { loginUri =3D null; regionUri =3D null; } return loginUri !=3D null && regionUri !=3D null; } public IEnumerator PreAuthenticatedLogin(Uri loginUri, Uri regionUri) { OSDMap request; OSDMap response =3D null; // 1. POST to the pre-authenticated loginUri and receive an agent_s= eed_capability request =3D new OSDMap(); yield return StartCoroutine(PostLLSD(loginUri.ToString(), request, = delegate(OSDMap ret) { response =3D ret; })); if (response =3D=3D null || !response.ContainsKey("agent_seed_capab= ility")) { DebugConsole.Log("Login failed POSTing to loginuri " + loginUri= + ", response=3D\"" + response + "\""); yield break; } string agentSeedCapUrl =3D response["agent_seed_capability"].AsStri= ng(); // 2. POST to the agent_seed_capability and get a list of capabilit= ies request =3D new OSDMap(); request["agent/info"] =3D new OSDMap(); request["agent/session"] =3D new OSDMap(); yield return StartCoroutine(PostLLSD(agentSeedCapUrl, request, dele= gate(OSDMap ret) { response =3D ret; })); if (response =3D=3D null || !(response["agent/info"] is OSDMap) || = !(response["agent/session"] is OSDMap)) { DebugConsole.Log("Login failed POSTing to agent_seed_capability= " + agentSeedCapUrl + ", response=3D\"" + response + "\""); yield break; } string agentInfoUrl =3D ((OSDMap)response["agent/info"])["uri"].AsS= tring(); string agentSessionUrl =3D ((OSDMap)response["agent/session"])["uri= "].AsString(); // 3. GET agent/info to get our agent_id, name, and home/last locat= ions yield return StartCoroutine(GetLLSD(agentInfoUrl, delegate(OSDMap r= et) { response =3D ret; })); if (response =3D=3D null || !response.ContainsKey("agent_id")) { DebugConsole.Log("Login failed POSTing to agent/info " + agentS= eedCapUrl + ", response=3D\"" + response + "\""); yield break; } UUID agentID =3D response["agent_id"].AsUUID(); string name =3D response["name"].AsString(); // 4. GET agent/session to get our session_id and secure_session_id yield return StartCoroutine(GetLLSD(agentSessionUrl, delegate(OSDMa= p ret) { response =3D ret; })); if (response =3D=3D null || !response.ContainsKey("session_id")) { DebugConsole.Log("Login failed POSTing to agent/session " + age= ntSeedCapUrl + ", response=3D\"" + response + "\""); yield break; } UUID sessionID =3D response["session_id"].AsUUID(); // 5. POST to the regionUri (public region seed capability) to get = the rez_avatar/place capability request =3D new OSDMap(); request["rez_avatar/place"] =3D new OSDMap(); yield return StartCoroutine(PostLLSD(regionUri.ToString(), request,= delegate(OSDMap ret) { response =3D ret; })); if (response =3D=3D null || !(response["rez_avatar/place"] is OSDMa= p)) { DebugConsole.Log("Login failed POSTing to public region seed ca= pabability " + regionUri + ", response=3D\"" + response + "\""); yield break; } string rezAvatarPlaceUrl =3D ((OSDMap)response["rez_avatar/place"])= ["uri"].AsString(); // 6. POST to rez_avatar/place to get the region_seed_capability request =3D new OSDMap(); request["public_region_seed_capability"] =3D OSD.FromUri(regionUri)= ; // TODO: request["position"] =3D OSD.FromVector3(...); yield return StartCoroutine(PostLLSD(rezAvatarPlaceUrl, request, de= legate(OSDMap ret) { response =3D ret; })); if (response =3D=3D null || !response["connect"].AsBoolean() || !re= sponse.ContainsKey("region_seed_capability")) { DebugConsole.Log("Login failed POSTing to rez_avatar/place " + = rezAvatarPlaceUrl + ", response=3D\"" + response + "\""); yield break; } string regionSeedCapUrl =3D response["region_seed_capability"].AsSt= ring(); // 7. POST to region_seed_capability to get the region capabilities request =3D new OSDMap(); request["websocket_event_queue"] =3D new OSDMap(); yield return StartCoroutine(PostLLSD(regionSeedCapUrl, request, del= egate(OSDMap ret) { response =3D ret; })); if (response =3D=3D null || !(response["websocket_event_queue"] is = OSDMap)) { DebugConsole.Log("Login failed POSTing to region_seed_capabilit= y " + regionSeedCapUrl + ", response=3D\"" + response + "\""); yield break; } string websocketEventQueue =3D ((OSDMap)response["websocket_event_q= ueue"])["uri"].AsString(); // FIXME: Return the data we collected } public static IEnumerator PostLLSD(string url, OSDMap requestMap, Actio= n callback) { byte[] requestData =3D Encoding.UTF8.GetBytes(OSDParser.SerializeJs= onString(requestMap)); Hashtable headers =3D new Hashtable(); headers["Content-Type"] =3D "application/json+llsd"; WWW request =3D new WWW(url, requestData, headers); =20 yield return request; if (!String.IsNullOrEmpty(request.error)) DebugConsole.Log("Error posting data to " + url + ": " + reques= t.error); if (request.bytes !=3D null && request.bytes.Length > 0) { OSDMap responseMap =3D OSDParser.Deserialize(request.bytes) as = OSDMap; callback(responseMap); } else { callback(null); } } public static IEnumerator GetLLSD(string url, Action callback) { WWW request =3D new WWW(url); yield return request; if (!String.IsNullOrEmpty(request.error)) DebugConsole.Log("Error posting data to " + url + ": " + reques= t.error); if (request.bytes !=3D null && request.bytes.Length > 0) { OSDMap responseMap =3D OSDParser.Deserialize(request.bytes) as = OSDMap; callback(responseMap); } else { callback(null); } } } From carlo@alinoe.com Fri Apr 9 05:17:37 2010 Return-Path: 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 3AA7E3A68E7 for ; Fri, 9 Apr 2010 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[AWL=-1.489, BAYES_50=0.001, FM_IS_IT_OUR_ACCOUNT=4.2, GB_I_LETTER=-2, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 dzUPzpi-8wIs for ; Fri, 9 Apr 2010 05:17:34 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 055103A684A for ; Fri, 9 Apr 2010 05:17:33 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep13-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100409121727.LVXJ14401.viefep13-int.chello.at@edge03.upcmail.net>; Fri, 9 Apr 2010 14:17:27 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id 3QHR1e03F0FlQed03QHSM1; Fri, 09 Apr 2010 14:17:27 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1O0D9J-0002t5-5e; Fri, 09 Apr 2010 14:17:25 +0200 Date: Fri, 9 Apr 2010 14:17:25 +0200 From: Carlo Wood To: "dyerbrookme@juno.com" Message-ID: <20100409121725.GA10972@alinoe.com> References: <20100407.200744.23911.0@webmail08.vgs.untd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100407.200744.23911.0@webmail08.vgs.untd.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=MQuG_ZtAow4A:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=NoAKp6exAAAA:8 a=69EAbJreAAAA:8 a=48vgC7mUAAAA:8 a=n-kJSqksAAAA:8 a=mK_AVkanAAAA:8 a=iXggwkVfAAAA:8 a=cfHPFXhNAAAA:8 a=BjFOTwK7AAAA:8 a=WQdLFznJqp6S4VKmCM0A:9 a=JKB8Sw8IlBlSoe3F2-4A:7 a=A25VMUuLjUHk_bITrme4F8163zsA:4 a=CjuIK1q_8ugA:10 a=cAxOMMiSbzoA:10 a=B0cvAcWxpcAA:10 a=EfJqPEOeqlMA:10 a=lZB815dzVvQA:10 a=98jSFH7WqmUA:10 a=9xyTavCNlvEA:10 a=x6U5xrJgyBEA:10 a=duT3nmX5SCmDhvhI:21 a=_YoUQQsliRvkk5Bd:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] Removing first name / last name assumptions? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:17:37 -0000 You need to seek help (from a psychologist). On Thu, Apr 08, 2010 at 12:07:44AM +0000, dyerbrookme@juno.com wrote: > It's hardly "trolling" to state the truth of what is going on here: technologists are deciding very gravely important issues for users, without user imput simply because a) it is too technical b) it is too sprawling and c) it is too hard to justify attention and education of oneself on the issues when it might merely be to discover that the fight was over using....the IRC channel or Joombla. Sigh. > > *You're* trolling as you always do on the Concierge list every time I speak up critically about the abusive Emerald devs and viewer and in support of the Third Party Viewer policy (which Emerald has not signed). > > The idea that "people from all over the world" involved in a...wonky obscure list on VWRP that even tekkies might find hard to follow qualifies something as "open" and "free" is indicative of the very problem I'm identifying. > > And this very arrogant statement itself: "If the mass have interest in the VWRAP well they are free to express them self right here no one will be rejected." -- and then telling me to shut up and not "troll" (!) let's us know how REALLY free it is. > > Tekkies project much when they invoke this discredited old early web and Well notion of "trolling". In normal society, people asking persistent questions of those in power and making pointed statements about their discrepancies are called "citizens" not "trolls". > > LL may be able to resign anytime they think this project is not secure for its users, but hey, it's *Lindens* resigning who are *still on the project* (!) that lets us know that we are right to be concerned about security, given some of the extremity of their opensource zealotry, and given the rumours that they resigned over the Third Party Viewer policy. Furthermore, Lindens in conjunction with the most extreme of the crazies on the OS dev list, that even (remaining) Lindens have to now quell and put down, on *this* list makes us wonder if we are dealing with dvoyevlastiye (dual power). > > Re: "So far I see a bunch of very honest people who are trying to do (with the help of IBM and INTEL BTW.. ) the best protocol possible with their knowledge and the IETF knowledge as well which is the best entity of people on the internet to help develop such protocol. > > I don't have the touching faith in big IT companies that you do. I see them only too happy to harvest the free labour of opensource zealots and let a small company and its devotees to OS be the cat's paw for their larger agendas, as yet opaque. We all know they want to sell widgets. It's good that they make and sell widgets because we use widgets. But if they are knocking down the "walled garden" to sell widgets that put money in their pockets and destroy our privacy and IP that we were using to monetarize the VWs, hey, we want to hear more about the plan here. > > That's why I'm calling on big companies and small, individuals and ex-Lindens, to start making coherent *public* and *understandable statements* about *what you are doing here*. Transparency isn't saying belligerently "anyone can join this open list" or "anyone can learn to code and patch or GTFO". > > Real accountability with transparency is explaining in laymen's normal terms what the decisions are on this roadmap. How you are handling the controversies about permissions on objects. What the different schools of thought are among yourselves. How you plan to protect IP. How you plan to enable those who wish to keep anonymity to keep it intact. How you plan to enable those who want their avatar name's associations to survive across frontiers but without griefing. How you plan to preserve geographical contiguous space not only as a metaphor but as a structure for commerce -- or whether you will use the excuse of interop to drive people to big web stores like Xstreet. In short, it's a social demand for your accountability, which you must display along with your technical expertise in social media because it's social. > > All of these are good questions to be asking -- and answering. > > Prokofy > > > > ---------- Original Message ---------- > From: "Patnad Babii" > To: > Cc: > Subject: Re: [vwrap] Removing first name / last name assumptions? > Date: Wed, 7 Apr 2010 19:17:33 -0400 > > look prokofy. the people in this list aren't arrogant geek as you may think. > The people here are people from everywhere in the world and it can be > everyone as it is an open (on the internet) mailing list. So i don't know > why you keep trolling about *US* deciding for the mass. If the mass have > interest in the VWRAP well they are free to express them self right here no > one will be rejected. > > So please stop profaning your insanity THAT doesn't have a place here. We > (everyone in this list) are trying to establish a protocol to make virtual > world server communicate together, where LL can resign at anytime they see > fit if they think it is not something "SECURE" for their users or any other > maters. > > So far I see a bunch of very honest people who are trying to do (with the > help of IBM and INTEL BTW.. ) the best protocol possible with their > knowledge and the IETF knowledge as well which is the best entity of people > on the internet to help develop such protocol. > > > > -------------------------------------------------- > From: > Sent: Wednesday, April 07, 2010 12:43 PM > To: > Cc: > Subject: Re: [vwrap] Removing first name / last name assumptions? > > > A reminder that all of you are deciding highly personal -- and public --- > > matters like how names will be used and connected, how geographically > > contiguous space or location will be represented and accessed, and how > > content will be moved and rights preserved *without the general public* > > and *without a democratic process* to act as a curb on your own selfish > > interests, which are largely of the copyleftist and even Stallmanite > > school at the extreme. > > > > When we see the sheer insane unreason on the opensource dev list regarding > > the TPV from some of the people now migrating here to continue the same > > extremity, we have to wonder what's "up". > > > > Your flogging of these issues at the IETF is also suspect, given their > > undemocratic procedures, their "humming" and the "tyranny of who shows > > up*. > > > > As they say: I saw what you did there. > > > > Questions of naming, identity, space, connection, property, inventory, > > rights -- these are all human and social and people in the real world > > spent centuries fashioning laws and policies over them, often going to war > > of them. > > > > You imagine that a handful of you superior and arrogant geeks can decide > > these things for the Metaverse among yourselves, with no due process or > > elections, and with no representation of those most interested -- the > > users who pay for these servers and your salaries. > > > > You are trying to grab these issues without public participation merely > > because they are complex and technical so that you can hide behind > > "technology". But they aren't so complex that you can't explain them and > > their ramifications normally in laymen's terms, as this is done all the > > time when tekkies have to face civilian oversight. > > > > We see from the court defeat of Net Neutrality that the Google-run > > campaign flogged by the EFF and ACLU gulling the public with fake terms > > implying freedom of expression when it's about consumption and Google's > > loss-leader to view Youtube liberated content for free in the consumer's > > last mile, that checks and balances and reason prevail. And whatever you > > think you're getting away with now in hijacking the virtual world > > architecture discussion, you'll be stopped down the road with more > > government Internet regulation and you'll have only yourselves to blame. > > > > Even a little more democracy and a modicum of transparency could forestall > > this inevitability, if you were more fair, and didn't pretend that an > > obscure but technically accessible list like this is "transparency" and > > that an IETF workshop run by big companies is "participation". > > > > If you want credibility, Joshua Linden, regarding Linden Lab's true > > intentions with our virtual lives and stuff, and if you want to stem > > rumours that you were forced to leave due to your opensource extremism, > > Infinity ex-Linden, then you should do a post on the general Linden blog > > explaining in laymen's terms *just what the hell you are doing with the > > world and content which we created and paid for under the old mantra of > > 'Your World, Your Imagination' when you make it easier to pipe it to > > OpenSim, which is already rampant with content theft. > > > > If you are giving away the store -- and I see that you are -- then you owe > > it to the public to be honest about it and not slip it in as a > > technicality. > > > > There are policies on Third Party Viewers at long last that put some curb > > on the script kiddies and opensource fanatics that compromise property, > > privacy, and peace in Second Life due to TPV ripping, exposure, and > > griefing. > > > > Is there going to be an interop policy for Lindens and ex-Lindens and the > > big companies like IBM represented by Zha Ewry and Dale Innis, and Intel, > > represented by John Hurliman, the first maker and seller of copybot in > > Second Life? > > > > Prokofy Neva > > > > ---------- Original Message ---------- > > From: Tammy Nowotny > > To: Morgaine > > Cc: vwrap@ietf.org > > Subject: Re: [vwrap] Removing first name / last name assumptions? > > Date: Wed, 07 Apr 2010 06:10:17 -0400 > > > > Names are a small thing but they are immensely complicated (and > > important.) > > > > Morgaine wrote: > >> Thanks for confirming that, Joshua! > >> > >> The nature of the agent field is a small thing, but progress has been > >> made. :-) > >> > >> > >> Morgaine. > >> > >> > >> > >> > >> > >> ====================================== > >> > >> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell >> > wrote: > >> > >> Speaking for Linden: > >> > >> (1) For the purposes of VWRAP interop, it is acceptable to us to > >> assume that a human readable agent identifier ("name") for Second > >> Life can be coerced to and from a single string field. Today, SL > >> firstname/lastname pairs are constrained to a subset of ASCII that > >> disallows characters such as periods and spaces. Therefore, as has > >> been mentioned, it is possible today to unambiguously encode an SL > >> name as (firstname + "." + lastname) or (firstname + " " + lastname). > >> > >> (2) As mentioned > >> at > >> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead > >> and > >> at > >> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up > >> Linden > >> is investigating modifications to "names" in SL. However, it is > >> too early to comment on any details at this time. > >> > >> (3) That said, the investigative work for (2) is being done with > >> the benefits of (1) held firmly in mind. (As with practically > >> anything in the biz, this statement is not a contract or guarantee.) > >> > >> Therefore, from Linden's perspective, we can live with the > >> proposed simplified requirements of a single string. If it becomes > >> necessary to revisit that in the future we'll raise it. > >> > >> > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > > > > ____________________________________________________________ > > Get Free Email with Video Mail & Video Chat! > > http://www.juno.com/freeemail?refcd=JUTAGOUT1FREM0210 > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > ---------- Original Message ---------- > From: "Patnad Babii" > To: > Cc: > Subject: Re: [vwrap] Removing first name / last name assumptions? > Date: Wed, 7 Apr 2010 19:17:33 -0400 > > look prokofy. the people in this list aren't arrogant geek as you may think. > The people here are people from everywhere in the world and it can be > everyone as it is an open (on the internet) mailing list. So i don't know > why you keep trolling about *US* deciding for the mass. If the mass have > interest in the VWRAP well they are free to express them self right here no > one will be rejected. > > So please stop profaning your insanity THAT doesn't have a place here. We > (everyone in this list) are trying to establish a protocol to make virtual > world server communicate together, where LL can resign at anytime they see > fit if they think it is not something "SECURE" for their users or any other > maters. > > So far I see a bunch of very honest people who are trying to do (with the > help of IBM and INTEL BTW.. ) the best protocol possible with their > knowledge and the IETF knowledge as well which is the best entity of people > on the internet to help develop such protocol. > > > > -------------------------------------------------- > From: > Sent: Wednesday, April 07, 2010 12:43 PM > To: > Cc: > Subject: Re: [vwrap] Removing first name / last name assumptions? > > > A reminder that all of you are deciding highly personal -- and public --- > > matters like how names will be used and connected, how geographically > > contiguous space or location will be represented and accessed, and how > > content will be moved and rights preserved *without the general public* > > and *without a democratic process* to act as a curb on your own selfish > > interests, which are largely of the copyleftist and even Stallmanite > > school at the extreme. > > > > When we see the sheer insane unreason on the opensource dev list regarding > > the TPV from some of the people now migrating here to continue the same > > extremity, we have to wonder what's "up". > > > > Your flogging of these issues at the IETF is also suspect, given their > > undemocratic procedures, their "humming" and the "tyranny of who shows > > up*. > > > > As they say: I saw what you did there. > > > > Questions of naming, identity, space, connection, property, inventory, > > rights -- these are all human and social and people in the real world > > spent centuries fashioning laws and policies over them, often going to war > > of them. > > > > You imagine that a handful of you superior and arrogant geeks can decide > > these things for the Metaverse among yourselves, with no due process or > > elections, and with no representation of those most interested -- the > > users who pay for these servers and your salaries. > > > > You are trying to grab these issues without public participation merely > > because they are complex and technical so that you can hide behind > > "technology". But they aren't so complex that you can't explain them and > > their ramifications normally in laymen's terms, as this is done all the > > time when tekkies have to face civilian oversight. > > > > We see from the court defeat of Net Neutrality that the Google-run > > campaign flogged by the EFF and ACLU gulling the public with fake terms > > implying freedom of expression when it's about consumption and Google's > > loss-leader to view Youtube liberated content for free in the consumer's > > last mile, that checks and balances and reason prevail. And whatever you > > think you're getting away with now in hijacking the virtual world > > architecture discussion, you'll be stopped down the road with more > > government Internet regulation and you'll have only yourselves to blame. > > > > Even a little more democracy and a modicum of transparency could forestall > > this inevitability, if you were more fair, and didn't pretend that an > > obscure but technically accessible list like this is "transparency" and > > that an IETF workshop run by big companies is "participation". > > > > If you want credibility, Joshua Linden, regarding Linden Lab's true > > intentions with our virtual lives and stuff, and if you want to stem > > rumours that you were forced to leave due to your opensource extremism, > > Infinity ex-Linden, then you should do a post on the general Linden blog > > explaining in laymen's terms *just what the hell you are doing with the > > world and content which we created and paid for under the old mantra of > > 'Your World, Your Imagination' when you make it easier to pipe it to > > OpenSim, which is already rampant with content theft. > > > > If you are giving away the store -- and I see that you are -- then you owe > > it to the public to be honest about it and not slip it in as a > > technicality. > > > > There are policies on Third Party Viewers at long last that put some curb > > on the script kiddies and opensource fanatics that compromise property, > > privacy, and peace in Second Life due to TPV ripping, exposure, and > > griefing. > > > > Is there going to be an interop policy for Lindens and ex-Lindens and the > > big companies like IBM represented by Zha Ewry and Dale Innis, and Intel, > > represented by John Hurliman, the first maker and seller of copybot in > > Second Life? > > > > Prokofy Neva > > > > ---------- Original Message ---------- > > From: Tammy Nowotny > > To: Morgaine > > Cc: vwrap@ietf.org > > Subject: Re: [vwrap] Removing first name / last name assumptions? > > Date: Wed, 07 Apr 2010 06:10:17 -0400 > > > > Names are a small thing but they are immensely complicated (and > > important.) > > > > Morgaine wrote: > >> Thanks for confirming that, Joshua! > >> > >> The nature of the agent field is a small thing, but progress has been > >> made. :-) > >> > >> > >> Morgaine. > >> > >> > >> > >> > >> > >> ====================================== > >> > >> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell >> > wrote: > >> > >> Speaking for Linden: > >> > >> (1) For the purposes of VWRAP interop, it is acceptable to us to > >> assume that a human readable agent identifier ("name") for Second > >> Life can be coerced to and from a single string field. Today, SL > >> firstname/lastname pairs are constrained to a subset of ASCII that > >> disallows characters such as periods and spaces. Therefore, as has > >> been mentioned, it is possible today to unambiguously encode an SL > >> name as (firstname + "." + lastname) or (firstname + " " + lastname). > >> > >> (2) As mentioned > >> at > >> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead > >> and > >> at > >> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up > >> Linden > >> is investigating modifications to "names" in SL. However, it is > >> too early to comment on any details at this time. > >> > >> (3) That said, the investigative work for (2) is being done with > >> the benefits of (1) held firmly in mind. (As with practically > >> anything in the biz, this statement is not a contract or guarantee.) > >> > >> Therefore, from Linden's perspective, we can live with the > >> proposed simplified requirements of a single string. If it becomes > >> necessary to revisit that in the future we'll raise it. > >> > >> > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > > > > ____________________________________________________________ > > Get Free Email with Video Mail & Video Chat! > > http://www.juno.com/freeemail?refcd=JUTAGOUT1FREM0210 > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > ____________________________________________________________ > Penny Stock Jumping 2000% > Sign up to the #1 voted penny stock newsletter for free today! > http://thirdpartyoffers.juno.com/TGL3141/4bbd1e90d929f143e24st04vuc > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Carlo Wood From carlo@alinoe.com Fri Apr 9 06:38:58 2010 Return-Path: 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 240D43A6862 for ; Fri, 9 Apr 2010 06:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SARE_MILLIONSOF=0.315] 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 G6HDyKu+2Tlq for ; Fri, 9 Apr 2010 06:38:55 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id A72B33A68ED for ; Fri, 9 Apr 2010 06:38:12 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep13-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100409133806.QXHX14401.viefep13-int.chello.at@edge01.upcmail.net>; Fri, 9 Apr 2010 15:38:06 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id 3Re41e0080FlQed01Re5Yj; Fri, 09 Apr 2010 15:38:06 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from ) id 1O0EPL-0003VD-Rx; Fri, 09 Apr 2010 15:38:03 +0200 Date: Fri, 9 Apr 2010 15:38:03 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20100409133803.GB10972@alinoe.com> References: <4BBB7705.4060206@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=OC2PQ51RjLMA:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=qBSlilM2ILOq261215AA:9 a=uDWO7dwkNaqCtEmh_rYA:7 a=hs-wnX1X1BWn1wGssUgUyqSZlWgA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=W3OhdButrUtGI0ST:21 a=2wW4FigcAVIxbKBl:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: [vwrap] We need protocol negotiation to be builtin. (was: authentication : remove reference to MD5) X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:38:58 -0000 On Tue, Apr 06, 2010 at 11:22:58AM -0700, Meadhbh Hamrick wrote: > so the question is, to which degree do we add an engineering burden to > existing implementations that would like to adopt this group's output? > the question of the two string identifier is a good one. linden could > probably make systems that adhere to all sorts of different changes. > but to what degree to we make it easy for existing implementers vs. > the desires of people who have yet to build and implementation? I think that the worst we can do is to make a standard that isn't as good as it could have been. In other words, we don't want a "legacy" bug in the protocol. However, nothing, absolutely nothing, cannot be solved by adding protocol negotiation to VWRAP. For example, we define the standard to use SHA256. But Linden Lab adds an extension, negotiated with the client at connection, to use an MD5 hash. Surely you're not afraid that viewer developers will refuse to support that ;). Lets have a look at the effects of my protocol negotation proposal again: 1) It will allow us to make mistakes now, and fix them entirely in the future. 2) It will allow us to make a start with the protocol, and complete it in the future. 3) It will allow easy transitions of legacy protocols to the standard over an arbitrary period of backwards compatibility. 4) It might, hopefully, lead to protocol evolution, where good changes of the protocol are copied by everyone; causing the Virtual World protocol to evolve into a better and better protocol without limits, without becoming a legacy burden. Think about it: ALREADY Linden Lab is complaining that VWRAP can't do this and should do that because it's hard for them to implement it otherwise. THAT WILL ONLY GET *MUCH* WORSE! Once we have hunderds of grids, thousands of viewers and ten millions of users, it will be IMPOSSIBLE to change the protocol. It will be become one big legacy nightmare with no possibility to fix things. Don't think for a second that we are capable of designing the perfect protocol right now, before anything like all this exists (and don't tell me that Linden Labs current protocol is the perfect protocol already). --- Recap of the TECHNICAL DETAILS: The protocol negotiation system exists of two equally important parts: 1) Negotiation of "Features". 2) Documentation of "Features". Lets forget the documentation part of a moment, just assume that it is possible to easily find how to implement any feature. Then the protocol negotiation boils down to negotiations of booleans: Yes or No this feature. There are two types of features: mandatory (M) features and optional (O) features. For each connection between two hosts, there is a protocol negotiation and thus there are two sides (A and B) that both can have mandatory or optional features. The total number of possibly combinations for any given feature are therefore: X: unknown or not implemented (non-existant) O: Optional M: Mandatory A B result X X not used X O not used X M incompatible O X not used O O used (or not?) O M used M X incompatible M O used M M used There is another level of compatibility however, besides whether a mandatory feature is available on both sides: compatiblity of the negotiation itself. Namely, in order to be able to "shift the origin" of the protocol, it must be possible to make a mandatory option part of the "base" of the protocol (for which no negotiation is needed). In otherwords, a feature has four states: Protocol version p X: non-eXistent p < V N: Not implemented V <= p < W O: Optional V <= p < W M: Mandatory (negotiated) V <= p < W B: Base protocol W < p Negotiation of such a feature will fail if one side assumes the feature is in the Base (assumed mandatory), while the other side doesn't even know of it's existance (X). This is where the (negotiation) compatibility version comes in: if a new feature is introduced in an implementation Foo at version V, then implementations made for Foo of an earlier version does not know about that feature. That is not a problem however, until that feature is made a part of the Base protocol in version W > V. Thus, each side tells eachother their "protocol version", and the side with the largest version decides if they are compatible by comparing the smaller version with the "compatibility version" V (in the case above the "compatibility version" of W is V). How does one determine the "compatibility version"? This is simple: it is the smallest version where every feature that is part of the base protocol in the current version still existed (and did exist in all versions in between). This simple compare then takes care of (B,X) and (X,B) pairs: they won't exist if the smaller version is larger or equal than then the compatiblity version of the larger version. Each implementation contains two version numbers (only) thus. After comparing versions, X and N collapse into X as used in the first table. EXAMPLE Implementation of Linden Lab server protocol 100, with compatiblity version 40. Viewer connects (supporting the "Linden Lab" protocol) with protocol version 50. Negotiation is allowed since 50 is not less than 40. The server tells the viewer that feature MD5HASH is mandatory. The viewer knows about this, because this feature was already part of the protocol since version 1. It has this feature as optional, and the negotiation results in it being used. The factual messages needed upon connect are: client connects client --> server: PROT (this requests protocol negotiation, without it, the legacy protocol is used) (possible other base protocol start up messages) server --> client: GRID LINDENLAB 100 40 (possible other LABEL CURVERSION COMPATVERSION triplets can be appended) client --> server: PROT REQ LINDENLAB 50 ENCRYPTION (ENCRYPTION is known *optional* in version 50) server --> client: PROT SET LINDENLAB 50 MD5HASH (server rejects ENCRYPTION because it is now version 100 and demands MD5HASH) (server switches to feature set for outgoing messages here) client --> server: PROT ACK LINDENLAB 50 MD5HASH (client agrees, and signals it switches protocol here) (client switches to feature set for outgoing messages here) Now suppose that somewhere in the (far) future Linden Lab manages to switch to SHA256 passwords (ie, by having everyone register again), and they add the optional feature SHA256LOGIN in version 1000. Every client can still connect, because it is only optional. However, again a few years later when all viewers caught up with the new feature, it is made mandatory in version 1100 (say). Then the protocol negotiation could look as follows: client --> server: PROT (without this, viewer is rejected as being incompatible) server --> client: GRID LINDENLAB 1100 1000 OPENSIM 878 512 CABLEBEACH 1250 733 client --> server: PROT REQ LINDENLAB 1050 OGRE LIPSYNC server --> client: PROT SET LINDENLAB 1040 OGRE client --> server: PROT ACK LINDENLAB 1040 OGRE and the MD5HASH legacy feature has completely vanished from the negotiation: the protocol has now shifted truely to the standard (or rather, to LINDENLAB version 1000). -- Carlo Wood From sean@uci.edu Fri Apr 9 09:31:22 2010 Return-Path: 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 9CA283A680E for ; Fri, 9 Apr 2010 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 GBdV1dByPbfp for ; Fri, 9 Apr 2010 09:31:21 -0700 (PDT) Received: from smtp2.es.uci.edu (smtp2.es.uci.edu [128.200.80.28]) by core3.amsl.com (Postfix) with ESMTP id E588A3A695C for ; Fri, 9 Apr 2010 09:31:09 -0700 (PDT) Received: from [128.200.62.123] (sean.nac.uci.edu [128.200.62.123]) (authenticated bits=0) by smtp2.es.uci.edu (8.13.1/8.13.1) with ESMTP id o39GV3UI001260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Apr 2010 09:31:04 -0700 X-UCInetID: sean Message-ID: <4BBF5649.9060608@uci.edu> Date: Fri, 09 Apr 2010 09:31:05 -0700 From: Sean Hennessee Organization: NACS CCS User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: vwrap@ietf.org References: <4BBB7705.4060206@stpeter.im> <20100409133803.GB10972@alinoe.com> In-Reply-To: <20100409133803.GB10972@alinoe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] We need protocol negotiation to be builtin. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:31:22 -0000 +1 to protocol negotiation in VWRAP IMAP and POP3 have similar protocol negotiation tools, IMAP uses the CAPABILITY command and POP3 uses the CAPA command. These commands allow client and server to negotiate things like whether clear text logins are allowed, or if StartTLS is required, (essentially the same type of thing we were discussing wrt SHA256 vs MD5.) Considering VWRAP will be a fairly complicated protocol compared to IMAP and POP, some sort of capabilities tool or protocol negotiation will be indispensable. POP/IMAP stuff here: http://www.faqs.org/rfcs/rfc2595.html (Search for 'capability' for examples.) Peace, Sean Carlo Wood wrote: > On Tue, Apr 06, 2010 at 11:22:58AM -0700, Meadhbh Hamrick wrote: >> so the question is, to which degree do we add an engineering burden to >> existing implementations that would like to adopt this group's output? >> the question of the two string identifier is a good one. linden could >> probably make systems that adhere to all sorts of different changes. >> but to what degree to we make it easy for existing implementers vs. >> the desires of people who have yet to build and implementation? > > I think that the worst we can do is to make a standard that isn't > as good as it could have been. > > In other words, we don't want a "legacy" bug in the protocol. > > However, > nothing, absolutely nothing, cannot be solved by adding protocol > negotiation to VWRAP. > > For example, we define the standard to use SHA256. But Linden Lab > adds an extension, negotiated with the client at connection, to > use an MD5 hash. Surely you're not afraid that viewer developers > will refuse to support that ;). > > Lets have a look at the effects of my protocol negotation proposal again: > > 1) It will allow us to make mistakes now, and fix them entirely in the future. > 2) It will allow us to make a start with the protocol, and complete it in the future. > 3) It will allow easy transitions of legacy protocols to the standard over an > arbitrary period of backwards compatibility. > 4) It might, hopefully, lead to protocol evolution, where good changes of the protocol > are copied by everyone; causing the Virtual World protocol to evolve into > a better and better protocol without limits, without becoming a legacy burden. > > Think about it: ALREADY Linden Lab is complaining that VWRAP can't do > this and should do that because it's hard for them to implement it otherwise. > THAT WILL ONLY GET *MUCH* WORSE! Once we have hunderds of grids, thousands > of viewers and ten millions of users, it will be IMPOSSIBLE to change > the protocol. It will be become one big legacy nightmare with no possibility > to fix things. > > Don't think for a second that we are capable of designing the perfect > protocol right now, before anything like all this exists (and don't > tell me that Linden Labs current protocol is the perfect protocol > already). > > --- > > Recap of the TECHNICAL DETAILS: > > The protocol negotiation system exists of two equally important parts: > > 1) Negotiation of "Features". > 2) Documentation of "Features". > > Lets forget the documentation part of a moment, just assume that > it is possible to easily find how to implement any feature. > Then the protocol negotiation boils down to negotiations of booleans: > Yes or No this feature. > > There are two types of features: mandatory (M) features and optional (O) features. > For each connection between two hosts, there is a protocol negotiation > and thus there are two sides (A and B) that both can have mandatory or optional > features. The total number of possibly combinations for any given feature > are therefore: > X: unknown or not implemented (non-existant) > O: Optional > M: Mandatory > > A B result > > X X not used > X O not used > X M incompatible > O X not used > O O used (or not?) > O M used > M X incompatible > M O used > M M used > > There is another level of compatibility however, besides whether a mandatory > feature is available on both sides: compatiblity of the negotiation itself. > > Namely, in order to be able to "shift the origin" of the protocol, it must > be possible to make a mandatory option part of the "base" of the protocol > (for which no negotiation is needed). > > In otherwords, a feature has four states: > > Protocol version p > X: non-eXistent p < V > N: Not implemented V <= p < W > O: Optional V <= p < W > M: Mandatory (negotiated) V <= p < W > B: Base protocol W < p > > Negotiation of such a feature will fail if one side assumes the feature > is in the Base (assumed mandatory), while the other side doesn't even > know of it's existance (X). This is where the (negotiation) compatibility > version comes in: if a new feature is introduced in an implementation > Foo at version V, then implementations made for Foo of an earlier version > does not know about that feature. That is not a problem however, until > that feature is made a part of the Base protocol in version W > V. > > Thus, each side tells eachother their "protocol version", and the side > with the largest version decides if they are compatible by comparing > the smaller version with the "compatibility version" V (in the case > above the "compatibility version" of W is V). > > How does one determine the "compatibility version"? This is simple: > it is the smallest version where every feature that is part of the base > protocol in the current version still existed (and did exist in all > versions in between). > > This simple compare then takes care of (B,X) and (X,B) pairs: they > won't exist if the smaller version is larger or equal than then > the compatiblity version of the larger version. > > Each implementation contains two version numbers (only) thus. > After comparing versions, X and N collapse into X as used in the first table. > > EXAMPLE > > Implementation of Linden Lab server protocol 100, with compatiblity > version 40. Viewer connects (supporting the "Linden Lab" protocol) > with protocol version 50. Negotiation is allowed since 50 is not > less than 40. > > The server tells the viewer that feature MD5HASH is mandatory. > The viewer knows about this, because this feature was already > part of the protocol since version 1. It has this feature as > optional, and the negotiation results in it being used. > > The factual messages needed upon connect are: > > client connects > client --> server: PROT (this requests protocol negotiation, without it, the legacy protocol is used) > (possible other base protocol start up messages) > server --> client: GRID LINDENLAB 100 40 (possible other LABEL CURVERSION COMPATVERSION triplets can be appended) > client --> server: PROT REQ LINDENLAB 50 ENCRYPTION (ENCRYPTION is known *optional* in version 50) > server --> client: PROT SET LINDENLAB 50 MD5HASH (server rejects ENCRYPTION because it is now version 100 and demands MD5HASH) > (server switches to feature set for outgoing messages here) > client --> server: PROT ACK LINDENLAB 50 MD5HASH (client agrees, and signals it switches protocol here) > (client switches to feature set for outgoing messages here) > > Now suppose that somewhere in the (far) future Linden Lab manages to > switch to SHA256 passwords (ie, by having everyone register again), > and they add the optional feature SHA256LOGIN in version 1000. > Every client can still connect, because it is only optional. > However, again a few years later when all viewers caught up with > the new feature, it is made mandatory in version 1100 (say). > Then the protocol negotiation could look as follows: > > client --> server: PROT (without this, viewer is rejected as being incompatible) > server --> client: GRID LINDENLAB 1100 1000 OPENSIM 878 512 CABLEBEACH 1250 733 > client --> server: PROT REQ LINDENLAB 1050 OGRE LIPSYNC > server --> client: PROT SET LINDENLAB 1040 OGRE > client --> server: PROT ACK LINDENLAB 1040 OGRE > > and the MD5HASH legacy feature has completely vanished > from the negotiation: the protocol has now shifted truely > to the standard (or rather, to LINDENLAB version 1000). > -- Sean Hennessee Central Computing Support Office of Information Technology UC Irvine ... . .- -. / .... . -. -. . ... ... . . From morgaine.dinova@googlemail.com Sat Apr 10 01:07:45 2010 Return-Path: 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 63C023A68A2 for ; Sat, 10 Apr 2010 01:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 LUyR3LU-9IPd for ; Sat, 10 Apr 2010 01:07:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B77153A67F5 for ; Sat, 10 Apr 2010 01:07:42 -0700 (PDT) Received: by wyb35 with SMTP id 35so241623wyb.31 for ; Sat, 10 Apr 2010 01:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=Q/EV5VNZd9LSmQssIF1eZwM8K5gz3NVRBpiU3CerWfY=; b=P0/9w59CwEF+GJd2D6z2MezpSrt9Raj5w6TB9cAeyY+R0QFFBLYcenOBWjZz2FLEIl MME6NAUwWpD7vakLtAhnb6PEUajQLkVj+wQWeUfTDrNckV1lW9QPgmC3WL4+3A1H6BcD rmrlQc+eFkYgSLYxgIyU5c+PZEXc9TxWDosKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NtIY6JZdnRLWrGkcJKeprQmzmPpY7TVy3R6pZPs6Q6OPKPcX4jlUWZgY8G2VuEkOyI A7W5iPoEwwotSPOdkDFBVx1ByeCs6Q0e/uqILfDY0d7ENyAOseTkwvMbwc2hurPukIgE GiS32So3j4W7FD3zWGFsZOyyCSPNWOffZPXU4= MIME-Version: 1.0 Received: by 10.216.28.146 with HTTP; Sat, 10 Apr 2010 01:07:35 -0700 (PDT) In-Reply-To: <20100409133803.GB10972@alinoe.com> References: <4BBB7705.4060206@stpeter.im> <20100409133803.GB10972@alinoe.com> Date: Sat, 10 Apr 2010 09:07:35 +0100 Received: by 10.216.182.78 with SMTP id n56mr629251wem.148.1270886855381; Sat, 10 Apr 2010 01:07:35 -0700 (PDT) Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e6497dfc9093400483dd67c1 Subject: Re: [vwrap] We need protocol negotiation to be builtin. (was: authentication : remove reference to MD5) X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 08:07:45 -0000 --0016e6497dfc9093400483dd67c1 Content-Type: text/plain; charset=ISO-8859-1 +1 for feature negotiation. +1 for protocol negotiation. Really there is no good alternative to feature negotiation when a single client application has to work with countless worlds in a huge metaverse. Diversity among worlds is inevitable, not only because of progress, but also because product differentiation drives business. The client and server endpoints are likely to have fully identical feature sets only by rare coincidence in a metaverse of interop. Likewise for protocol negotiation, it is needed to cope with protocol evolution among countless worlds, services, and clients. It is not viable for each evolutionary protocol change to have to revisit this working group. At best we are providing an initial framework and a launching pad for what VWRAP will become. Protocol negotiation will be required for two reasons, first because all protocol options will not always be available, and second because the base protocol must be able to evolve as well. We have many times stated that VWRAP is to be an extensible protocol, and what this means in practice is that both protocol options and the base protocol need to be negotiated. Endpoints will need to detect protocol variation and adapt, otherwise broad interop will be nothing but a wish. Carlo's points are well stated. While the actual mechanism and details of feature and protocol negotiation are a matter for much more analysis, providing negotiation machinery isn't really optional if the protocol is to be of value to numerous worlds and applications that evolve far beyond the current legacy generation. Morgaine. ======================================= On Fri, Apr 9, 2010 at 2:38 PM, Carlo Wood wrote: > On Tue, Apr 06, 2010 at 11:22:58AM -0700, Meadhbh Hamrick wrote: > > so the question is, to which degree do we add an engineering burden to > > existing implementations that would like to adopt this group's output? > > the question of the two string identifier is a good one. linden could > > probably make systems that adhere to all sorts of different changes. > > but to what degree to we make it easy for existing implementers vs. > > the desires of people who have yet to build and implementation? > > I think that the worst we can do is to make a standard that isn't > as good as it could have been. > > In other words, we don't want a "legacy" bug in the protocol. > > However, > nothing, absolutely nothing, cannot be solved by adding protocol > negotiation to VWRAP. > > For example, we define the standard to use SHA256. But Linden Lab > adds an extension, negotiated with the client at connection, to > use an MD5 hash. Surely you're not afraid that viewer developers > will refuse to support that ;). > > Lets have a look at the effects of my protocol negotation proposal again: > > 1) It will allow us to make mistakes now, and fix them entirely in the > future. > 2) It will allow us to make a start with the protocol, and complete it in > the future. > 3) It will allow easy transitions of legacy protocols to the standard over > an > arbitrary period of backwards compatibility. > 4) It might, hopefully, lead to protocol evolution, where good changes of > the protocol > are copied by everyone; causing the Virtual World protocol to evolve into > a better and better protocol without limits, without becoming a legacy > burden. > > Think about it: ALREADY Linden Lab is complaining that VWRAP can't do > this and should do that because it's hard for them to implement it > otherwise. > THAT WILL ONLY GET *MUCH* WORSE! Once we have hunderds of grids, thousands > of viewers and ten millions of users, it will be IMPOSSIBLE to change > the protocol. It will be become one big legacy nightmare with no > possibility > to fix things. > > Don't think for a second that we are capable of designing the perfect > protocol right now, before anything like all this exists (and don't > tell me that Linden Labs current protocol is the perfect protocol > already). > > --- > > Recap of the TECHNICAL DETAILS: > > The protocol negotiation system exists of two equally important parts: > > 1) Negotiation of "Features". > 2) Documentation of "Features". > > Lets forget the documentation part of a moment, just assume that > it is possible to easily find how to implement any feature. > Then the protocol negotiation boils down to negotiations of booleans: > Yes or No this feature. > > There are two types of features: mandatory (M) features and optional (O) > features. > For each connection between two hosts, there is a protocol negotiation > and thus there are two sides (A and B) that both can have mandatory or > optional > features. The total number of possibly combinations for any given feature > are therefore: > X: unknown or not implemented (non-existant) > O: Optional > M: Mandatory > > A B result > > X X not used > X O not used > X M incompatible > O X not used > O O used (or not?) > O M used > M X incompatible > M O used > M M used > > There is another level of compatibility however, besides whether a > mandatory > feature is available on both sides: compatiblity of the negotiation itself. > > Namely, in order to be able to "shift the origin" of the protocol, it must > be possible to make a mandatory option part of the "base" of the protocol > (for which no negotiation is needed). > > In otherwords, a feature has four states: > > Protocol version p > X: non-eXistent p < V > N: Not implemented V <= p < W > O: Optional V <= p < W > M: Mandatory (negotiated) V <= p < W > B: Base protocol W < p > > Negotiation of such a feature will fail if one side assumes the feature > is in the Base (assumed mandatory), while the other side doesn't even > know of it's existance (X). This is where the (negotiation) compatibility > version comes in: if a new feature is introduced in an implementation > Foo at version V, then implementations made for Foo of an earlier version > does not know about that feature. That is not a problem however, until > that feature is made a part of the Base protocol in version W > V. > > Thus, each side tells eachother their "protocol version", and the side > with the largest version decides if they are compatible by comparing > the smaller version with the "compatibility version" V (in the case > above the "compatibility version" of W is V). > > How does one determine the "compatibility version"? This is simple: > it is the smallest version where every feature that is part of the base > protocol in the current version still existed (and did exist in all > versions in between). > > This simple compare then takes care of (B,X) and (X,B) pairs: they > won't exist if the smaller version is larger or equal than then > the compatiblity version of the larger version. > > Each implementation contains two version numbers (only) thus. > After comparing versions, X and N collapse into X as used in the first > table. > > EXAMPLE > > Implementation of Linden Lab server protocol 100, with compatiblity > version 40. Viewer connects (supporting the "Linden Lab" protocol) > with protocol version 50. Negotiation is allowed since 50 is not > less than 40. > > The server tells the viewer that feature MD5HASH is mandatory. > The viewer knows about this, because this feature was already > part of the protocol since version 1. It has this feature as > optional, and the negotiation results in it being used. > > The factual messages needed upon connect are: > > client connects > client --> server: PROT (this requests protocol negotiation, > without it, the legacy protocol is used) > (possible other base protocol start up messages) > server --> client: GRID LINDENLAB 100 40 (possible other > LABEL CURVERSION COMPATVERSION triplets can be appended) > client --> server: PROT REQ LINDENLAB 50 ENCRYPTION (ENCRYPTION is > known *optional* in version 50) > server --> client: PROT SET LINDENLAB 50 MD5HASH (server rejects > ENCRYPTION because it is now version 100 and demands MD5HASH) > (server switches to feature set for outgoing messages here) > client --> server: PROT ACK LINDENLAB 50 MD5HASH (client agrees, and > signals it switches protocol here) > (client switches to feature set for outgoing messages here) > > Now suppose that somewhere in the (far) future Linden Lab manages to > switch to SHA256 passwords (ie, by having everyone register again), > and they add the optional feature SHA256LOGIN in version 1000. > Every client can still connect, because it is only optional. > However, again a few years later when all viewers caught up with > the new feature, it is made mandatory in version 1100 (say). > Then the protocol negotiation could look as follows: > > client --> server: PROT (without this, viewer is rejected as being > incompatible) > server --> client: GRID LINDENLAB 1100 1000 OPENSIM 878 512 CABLEBEACH 1250 > 733 > client --> server: PROT REQ LINDENLAB 1050 OGRE LIPSYNC > server --> client: PROT SET LINDENLAB 1040 OGRE > client --> server: PROT ACK LINDENLAB 1040 OGRE > > and the MD5HASH legacy feature has completely vanished > from the negotiation: the protocol has now shifted truely > to the standard (or rather, to LINDENLAB version 1000). > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016e6497dfc9093400483dd67c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for feature negotiation.

+1 for protocol negotiation.

Real= ly there is no good alternative to feature negotiation when a single client= application has to work with countless worlds in a huge metaverse.=A0 Dive= rsity among worlds is inevitable, not only because of progress, but also be= cause product differentiation drives business.=A0 The client and server end= points are likely to have fully identical feature sets only by rare coincid= ence in a metaverse of interop.

Likewise for protocol negotiation, it is needed to cope with protocol e= volution among countless worlds, services, and clients.=A0 It is not viable= for each evolutionary protocol change to have to revisit this working grou= p.=A0 At best we are providing an initial framework and a launching pad for= what VWRAP will become.

Protocol negotiation will be required for two reasons, first because al= l protocol options will not always be available, and second because the bas= e protocol must be able to evolve as well.=A0 We have many times stated tha= t VWRAP is to be an extensible protocol, and what this means in practice is= that both protocol options and the base protocol need to be negotiated.=A0= Endpoints will need to detect protocol variation and adapt, otherwise broa= d interop will be nothing but a wish.

Carlo's points are well stated.=A0 While the actual mechanism and d= etails of feature and protocol negotiation are a matter for much more analy= sis, providing negotiation machinery isn't really optional if the proto= col is to be of value to numerous worlds and applications that evolve far b= eyond the current legacy generation.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Fri, Apr 9, 2010 at 2:38 = PM, Carlo Wood <ca= rlo@alinoe.com> wrote:
On Tue, Apr 06, 2= 010 at 11:22:58AM -0700, Meadhbh Hamrick wrote:
> so the question is, to which degree do we add an engineering burden to=
> existing implementations that would like to adopt this group's out= put?
> the question of the two string identifier is a good one. linden could<= br> > probably make systems that adhere to all sorts of different changes. > but to what degree to we make it easy for existing implementers vs. > the desires of people who have yet to build and implementation?

I think that the worst we can do is to make a standard that isn't
as good as it could have been.

In other words, we don't want a "legacy" bug in the protocol.=

However,
nothing, absolutely nothing, cannot be solved by adding protocol
negotiation to VWRAP.

For example, we define the standard to use SHA256. But Linden Lab
adds an extension, negotiated with the client at connection, to
use an MD5 hash. Surely you're not afraid that viewer developers
will refuse to support that ;).

Lets have a look at the effects of my protocol negotation proposal again:
1) It will allow us to make mistakes now, and fix them entirely in the futu= re.
2) It will allow us to make a start with the protocol, and complete it in t= he future.
3) It will allow easy transitions of legacy protocols to the standard over = an
=A0 arbitrary period of backwards compatibility.
4) It might, hopefully, lead to protocol evolution, where good changes of t= he protocol
=A0 are copied by everyone; causing the Virtual World protocol to evolve i= nto
=A0 a better and better protocol without limits, without becoming a legacy= burden.

Think about it: ALREADY Linden Lab is complaining that VWRAP can't do this and should do that because it's hard for them to implement it othe= rwise.
THAT WILL ONLY GET *MUCH* WORSE! Once we have hunderds of grids, thousands<= br> of viewers and ten millions of users, it will be IMPOSSIBLE to change
the protocol. It will be become one big legacy nightmare with no possibilit= y
to fix things.

Don't think for a second that we are capable of designing the perfect protocol right now, before anything like all this exists (and don't
tell me that Linden Labs current protocol is the perfect protocol
already).

---

Recap of the TECHNICAL DETAILS:

The protocol negotiation system exists of two equally important parts:

1) Negotiation of "Features".
2) Documentation of "Features".

Lets forget the documentation part of a moment, just assume that
it is possible to easily find how to implement any feature.
Then the protocol negotiation boils down to negotiations of booleans:
Yes or No this feature.

There are two types of features: mandatory (M) features and optional (O) fe= atures.
For each connection between two hosts, there is a protocol negotiation
and thus there are two sides (A and B) that both can have mandatory or opti= onal
features. The total number of possibly combinations for any given feature are therefore:
X: unknown or not implemented (non-existant)
O: Optional
M: Mandatory

A B =A0 =A0 result

X X =A0 =A0 not used
X O =A0 =A0 not used
X M =A0 =A0 incompatible
O X =A0 =A0 not used
O O =A0 =A0 used (or not?)
O M =A0 =A0 used
M X =A0 =A0 incompatible
M O =A0 =A0 used
M M =A0 =A0 used

There is another level of compatibility however, besides whether a mandator= y
feature is available on both sides: compatiblity of the negotiation itself.=

Namely, in order to be able to "shift the origin" of the protocol= , it must
be possible to make a mandatory option part of the "base" of the = protocol
(for which no negotiation is needed).

In otherwords, a feature has four states:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Protocol ve= rsion p
X: non-eXistent =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p < V
N: Not implemented =A0 =A0 =A0 =A0 =A0 =A0 =A0V <=3D p < W
O: Optional =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V <=3D p < W
M: Mandatory (negotiated) =A0 =A0 =A0 V <=3D p < W
B: Base protocol =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0W < p

Negotiation of such a feature will fail if one side assumes the feature
is in the Base (assumed mandatory), while the other side doesn't even know of it's existance (X). This is where the (negotiation) compatibili= ty
version comes in: if a new feature is introduced in an implementation
Foo at version V, then implementations made for Foo of an earlier version does not know about that feature. That is not a problem however, until
that feature is made a part of the Base protocol in version W > V.

Thus, each side tells eachother their "protocol version", and the= side
with the largest version decides if they are compatible by comparing
the smaller version with the "compatibility version" V (in the ca= se
above the "compatibility version" of W is V).

How does one determine the "compatibility version"? This is simpl= e:
it is the smallest version where every feature that is part of the base
protocol in the current version still existed (and did exist in all
versions in between).

This simple compare then takes care of (B,X) and (X,B) pairs: they
won't exist if the smaller version is larger or equal than then
the compatiblity version of the larger version.

Each implementation contains two version numbers (only) thus.
After comparing versions, X and N collapse into X as used in the first tabl= e.

EXAMPLE

Implementation of Linden Lab server protocol 100, with compatiblity
version 40. Viewer connects (supporting the "Linden Lab" protocol= )
with protocol version 50. Negotiation is allowed since 50 is not
less than 40.

The server tells the viewer that feature MD5HASH is mandatory.
The viewer knows about this, because this feature was already
part of the protocol since version 1. It has this feature as
optional, and the negotiation results in it being used.

The factual messages needed upon connect are:

client connects
client --> server: PROT =A0 =A0 =A0 =A0 (this requests protocol negotiat= ion, without it, the legacy protocol is used)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (possible other base protocol start up= messages)
server --> client: GRID LINDENLAB 100 40 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= (possible other LABEL CURVERSION COMPATVERSION triplets can be appended) client --> server: PROT REQ LINDENLAB 50 ENCRYPTION =A0 =A0 (ENCRYPTION = is known *optional* in version 50)
server --> client: PROT SET LINDENLAB 50 MD5HASH =A0 =A0 =A0 =A0(server = rejects ENCRYPTION because it is now version 100 and demands MD5HASH)
=A0(server switches to feature set for outgoing messages here)
client --> server: PROT ACK LINDENLAB 50 MD5HASH =A0 =A0 =A0 =A0(client = agrees, and signals it switches protocol here)
=A0(client switches to feature set for outgoing messages here)

Now suppose that somewhere in the (far) future Linden Lab manages to
switch to SHA256 passwords (ie, by having everyone register again),
and they add the optional feature SHA256LOGIN in version 1000.
Every client can still connect, because it is only optional.
However, again a few years later when all viewers caught up with
the new feature, it is made mandatory in version 1100 (say).
Then the protocol negotiation could look as follows:

client --> server: PROT =A0 =A0 =A0 =A0 (without this, viewer is rejecte= d as being incompatible)
server --> client: GRID LINDENLAB 1100 1000 OPENSIM 878 512 CABLEBEACH 1= 250 733
client --> server: PROT REQ LINDENLAB 1050 OGRE LIPSYNC
server --> client: PROT SET LINDENLAB 1040 OGRE
client --> server: PROT ACK LINDENLAB 1040 OGRE

and the MD5HASH legacy feature has completely vanished
from the negotiation: the protocol has now shifted truely
to the standard (or rather, to LINDENLAB version 1000).

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e6497dfc9093400483dd67c1-- From josh@lindenlab.com Mon Apr 19 15:14:51 2010 Return-Path: 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 5150A3A6961 for ; Mon, 19 Apr 2010 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 uaY8t4y5zyxj for ; Mon, 19 Apr 2010 15:14:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 596DF3A6963 for ; Mon, 19 Apr 2010 15:14:14 -0700 (PDT) Received: by vws12 with SMTP id 12so206163vws.31 for ; Mon, 19 Apr 2010 15:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.73.13 with HTTP; Mon, 19 Apr 2010 15:14:01 -0700 (PDT) Date: Mon, 19 Apr 2010 15:14:01 -0700 Received: by 10.220.126.197 with SMTP id d5mr3983574vcs.121.1271715241919; Mon, 19 Apr 2010 15:14:01 -0700 (PDT) Message-ID: From: Joshua Bell To: vwrap@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [vwrap] "What's *not* in VWRAP" - presentation in SL April 20 @ 9:30am Pacific X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:14:51 -0000 Unless there's been a last minute schedule switcheroo I'm unaware of, I'll be presenting "What's *not* in VWRAP - a dissection of the Linden Lab Legacy Protocol" to the AWGroupies in Second Life on Tuesday, April 20th (thats tomorrow!) at 9:30am Pacific. I'm actually unsure of where the session will be held in-world. Can a regular please reply with a SLURL? This was material I'd intended to present at IETF77 in Anaheim but great content from other presenters took priority. The slides are linked from https://datatracker.ietf.org/meeting/77/materials.html but stick to the source at https://docs.google.com/present/edit?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en (I'm not planning on any last minute edits, though!) For those who look through the slides but may miss the context of the presentation: * The talk tries to give listeners a framework to answer the oft-asked question "When will XYZ be standardized in VWRAP?" * The talk is intended to be provocative; the slides make some bold claims I'm expecting the audience to take issue with! * There is no call for consensus on topics; contrariwise, there are calls for opening up discussions * It is not presented with any sort of implied authority, either as co-chair to the WG or as an employee of Linden Lab. The working group is highly encouraged to disagree with any of my reasoning or conclusions! The in-world presentation will not be under the auspices of the IETF (i.e. "Note Well" does not apply); any extensive discussion will be directed to this list, though. From dwl@us.ibm.com Mon Apr 19 17:45:29 2010 Return-Path: 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 2FC5A3A6926; Mon, 19 Apr 2010 17:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 d8xkXVXDuM2H; Mon, 19 Apr 2010 17:45:27 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 70D943A689B; Mon, 19 Apr 2010 17:45:27 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3K0XmS9019535; Mon, 19 Apr 2010 20:33:48 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3K0jBxf156772; Mon, 19 Apr 2010 20:45:11 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3K0jBVC000610; Mon, 19 Apr 2010 20:45:11 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3K0jB48000607; Mon, 19 Apr 2010 20:45:11 -0400 In-Reply-To: References: To: Joshua Bell MIME-Version: 1.0 X-KeepSent: EAD73D35:38920DE3-8525770B:000403F2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 19 Apr 2010 20:45:10 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/19/2010 20:45:10, Serialize complete at 04/19/2010 20:45:10 Content-Type: multipart/alternative; boundary="=_alternative 0004234D8525770B_=" Cc: vwrap@ietf.org, vwrap-bounces@ietf.org Subject: Re: [vwrap] "What's *not* in VWRAP" - presentation in SL April 20 @ 9:30am Pacific X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:45:29 -0000 This is a multipart message in MIME format. --=_alternative 0004234D8525770B_= Content-Type: text/plain; charset="US-ASCII" http://maps.secondlife.com/secondlife/ThorneBridgeTown/162/134/22 That's the ThorneBridgeTown IBM Research sim, if you want a teleport offer, tap Zha Ewry in world sometime around or after 9:20 PDT From: Joshua Bell To: vwrap@ietf.org Date: 04/19/2010 06:14 PM Subject: [vwrap] "What's *not* in VWRAP" - presentation in SL April 20 @ 9:30am Pacific Sent by: vwrap-bounces@ietf.org Unless there's been a last minute schedule switcheroo I'm unaware of, I'll be presenting "What's *not* in VWRAP - a dissection of the Linden Lab Legacy Protocol" to the AWGroupies in Second Life on Tuesday, April 20th (thats tomorrow!) at 9:30am Pacific. I'm actually unsure of where the session will be held in-world. Can a regular please reply with a SLURL? This was material I'd intended to present at IETF77 in Anaheim but great content from other presenters took priority. The slides are linked from https://datatracker.ietf.org/meeting/77/materials.html but stick to the source at https://docs.google.com/present/edit?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en (I'm not planning on any last minute edits, though!) For those who look through the slides but may miss the context of the presentation: * The talk tries to give listeners a framework to answer the oft-asked question "When will XYZ be standardized in VWRAP?" * The talk is intended to be provocative; the slides make some bold claims I'm expecting the audience to take issue with! * There is no call for consensus on topics; contrariwise, there are calls for opening up discussions * It is not presented with any sort of implied authority, either as co-chair to the WG or as an employee of Linden Lab. The working group is highly encouraged to disagree with any of my reasoning or conclusions! The in-world presentation will not be under the auspices of the IETF (i.e. "Note Well" does not apply); any extensive discussion will be directed to this list, though. _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap --=_alternative 0004234D8525770B_= Content-Type: text/html; charset="US-ASCII"
http://maps.secondlife.com/secondlife/ThorneBridgeTown/162/134/22

That's the ThorneBridgeTown  IBM Research sim, if you want a teleport offer, tap Zha Ewry in world sometime around or after  9:20 PDT



From: Joshua Bell <josh@lindenlab.com>
To: vwrap@ietf.org
Date: 04/19/2010 06:14 PM
Subject: [vwrap] "What's *not* in VWRAP" - presentation in SL April 20 @        9:30am Pacific
Sent by: vwrap-bounces@ietf.org




Unless there's been a last minute schedule switcheroo I'm unaware of,
I'll be presenting "What's *not* in VWRAP - a dissection of the Linden
Lab Legacy Protocol" to the AWGroupies in Second Life on Tuesday,
April 20th (thats tomorrow!) at 9:30am Pacific.

I'm actually unsure of where the session will be held in-world. Can a
regular please reply with a SLURL?

This was material I'd intended to present at IETF77 in Anaheim but
great content from other presenters took priority. The slides are
linked from https://datatracker.ietf.org/meeting/77/materials.html but
stick to the source at
https://docs.google.com/present/edit?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en
(I'm not planning on any last minute edits, though!)

For those who look through the slides but may miss the context of the
presentation:

* The talk tries to give listeners a framework to answer the oft-asked
question "When will XYZ be standardized in VWRAP?"
* The talk is intended to be provocative; the slides make some bold
claims I'm expecting the audience to take issue with!
* There is no call for consensus on topics; contrariwise, there are
calls for opening up discussions
* It is not presented with any sort of implied authority, either as
co-chair to the WG or as an employee of Linden Lab. The working group
is highly encouraged to disagree with any of my reasoning or
conclusions!

The in-world presentation will not be under the auspices of the IETF
(i.e. "Note Well" does not apply); any extensive discussion will be
directed to this list, though.
_______________________________________________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap

--=_alternative 0004234D8525770B_=-- From dzonatas@gmail.com Tue Apr 20 17:02:21 2010 Return-Path: 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 CA5563A693D for ; Tue, 20 Apr 2010 17:02:21 -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 MEKXsT6hnaPD for ; Tue, 20 Apr 2010 17:02:20 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 048243A6B63 for ; Tue, 20 Apr 2010 17:02:13 -0700 (PDT) Received: by ywh38 with SMTP id 38so3433054ywh.29 for ; Tue, 20 Apr 2010 17:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=bDeiifde5tKspG0hXpLOt1RqJhKaXG44CBggqpyXC/M=; b=kjQxBiRLc7v1WQzAn1iB3IxkHoYgIKdaNRdxyi5ihJqBrCSMb76vwxuxE6CBzXo6w/ S/zAJVI26l7RhSae9l6K//rSU7M3Wz6UVQOe1R8t+HcgLI7V6wsUEVAQTIwq2akyzrnf 5Jk3sabEgtDxkLf2Qh76qG0FuUlhVdIX3MyuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=FUJbDDt1aRYWbeVj+0yG7N4VHbmEEBTPeQnFZsz8s2q5yBMSzdhFKccaiqVAZ0qoQI aaRp2spyRebHi27e5f3+Cvdzq/hxe20i/oVjfcseQX4JGiSk9afzu/a8ya5MCgGcfOhT VCZc7uvLpKvM2pxinuE7GMiXmJlk5RhB1F0Hc= Received: by 10.101.108.5 with SMTP id k5mr18749451anm.122.1271808121800; Tue, 20 Apr 2010 17:02:01 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-126-141-37.dsl.scrm01.pacbell.net [68.126.141.37]) by mx.google.com with ESMTPS id i8sm2378189ana.9.2010.04.20.17.02.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 17:02:00 -0700 (PDT) Message-ID: <4BCE43ED.2040402@gmail.com> Date: Tue, 20 Apr 2010 17:16:45 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: vwrap@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] Follow-up from "What's *not* in VWRAP" presentation X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 00:02:21 -0000 As I worked on SNOW-375 ( https://jira.secondlife.com/browse/SNOW-375 , a REST/HTTP api for the viewer ), I also looked at the slides from the presentation: https://docs.google.com/a/lindenlab.com/present/view?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en There was some mention about what probably is better for http and what probably is better for udp, etc. I get the impression that a message queue is assumed to be a part of the server. If so, I think that influenced on what should and shouldn't travel through whatever channel by whatever protocol. It still seems open to change based on given solutions that implement any portion of vwrap. With SNOW-375, I haven't implemented the resource paths specifically, yet there is a overlap in functionality with VWRAP. What that in mind, it seems plausible to use different protocols/scheme-identifiers, like "udp://host:port/...", "ftp://..." , or "sql://..." rather then hardcode expected this-way or that-way for different message types. Let's say my program connects to the viewer and it provides a specific login process. As it connects through SNOW-375, it passes a capability list. I may want some messages to route through different paths and specify that at the connection. That specific connection message may contains this information (not specifically in this format): capability-xyz = http://localhost:8080/abc/capability-xyz capability-mno = http://localhost:8080/abc/capability-mno capability-pqr = http://localhost:8080/abc/capability-qrp capability-etc = http://localhost:8080/abc/capability-etc capability-def = udp://localhost:8080/abc/capability-def capability-ghi = udp://localhost:8080/abc/capability-ghi capability-jkl = udp://localhost:8080/abc/capability-jkl capability-stu = urn:lllp:legacy:stu capability-vwx = urn:lllp:legacy:vwx With the list above, the program can tell by connection rather to use one method or the other: 1) lookup capability identifier 2) return uri. Unless I missed something in the VWRAP docs, that main difference I suggest above is for the implementation to be more sensitive to the URI scheme instead of expect a pre-mapped capability to a particular scheme. I did notice some philosophy and further work put into VWRAP to allow such possibility, yet it may have been left open for debate to actually require this sensitivity as a standard. I think what was proposed by "What's *not* in VWRAP" is to establish a default capability-to-scheme map, which would vwrap implementation to proceed without full flexibility of other possible schemes per capability. This flexibility in schemes and capability lists reminds me of the old I-HAVE/SEND-ME uucp negotiations, which was very reliable between the many versions of programs to copy files back in forth. If you remember those days then you'll understand without further detail. From josh@lindenlab.com Tue Apr 20 17:32:00 2010 Return-Path: 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 61EF43A6880 for ; Tue, 20 Apr 2010 17:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 S4Go8nNKp8bo for ; Tue, 20 Apr 2010 17:31:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7E2FC3A67F0 for ; Tue, 20 Apr 2010 17:31:59 -0700 (PDT) Received: by vws10 with SMTP id 10so750611vws.31 for ; Tue, 20 Apr 2010 17:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.73.13 with HTTP; Tue, 20 Apr 2010 17:31:45 -0700 (PDT) In-Reply-To: <4BCE43ED.2040402@gmail.com> References: <4BCE43ED.2040402@gmail.com> Date: Tue, 20 Apr 2010 17:31:45 -0700 Received: by 10.220.157.196 with SMTP id c4mr1091885vcx.149.1271809905067; Tue, 20 Apr 2010 17:31:45 -0700 (PDT) Message-ID: From: Joshua Bell To: vwrap@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [vwrap] Follow-up from "What's *not* in VWRAP" presentation X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 00:32:00 -0000 On Tue, Apr 20, 2010 at 5:16 PM, Dzonatas Sol wrote: > > I think what was proposed by "What's *not* in VWRAP" is to establish a > default capability-to-scheme map, which would vwrap implementation to > proceed without full flexibility of other possible schemes per capability. Jeepers, I hope not! In a nutshell, the presentation said: * People ask "When is XYZ going to be included in VWRAP?" * The Linden Lab Legacy Protocol has lots of cruft in the subprotocols (there are more protocol message types for search than for scene graph updates!) * The VWRAP WG Charter outlines the things the WG is working on which form the core of interop (see the charter) * Maybe anything beyond that (e.g. search, world map, etc) don't need to be standardized at all in VWRAP as custom protocols and/or content types * Maybe, if they do need to be standardized, the minimum necessary for interop might be e.g. as URLs pointing at human-readable Web pages - e.g. when connecting to a world you could be given a mapping of {'search': 'http://search.thisvirtualworld.org', 'map': 'http://map.thisvirtualworld.org' } or some such. I dunno. * So... don't assume XYZ will be done the same way that LLLP does it, or that XYZ even needs to be in VWRAP * But if you believe that XYZ *is* necessary to specify for interop and should be part of VWRAP, then the onus is on you to advocate for it by writing specifications and providing implementations! There was also an aside in the presentation that pointed out that VWRAP will require transport(s) with a variety of characteristics (reliable/RESTful, reliable/streaming, unrealiable/streaming) and that investigation needs to be done, as is called out in the WG charter. From dzonatas@gmail.com Tue Apr 20 18:50:39 2010 Return-Path: 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 CD6A53A6BF6 for ; Tue, 20 Apr 2010 18:50:39 -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 ymvUuiVBSSPc for ; Tue, 20 Apr 2010 18:50:36 -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 355753A6AEF for ; Tue, 20 Apr 2010 18:50:32 -0700 (PDT) Received: by gyh4 with SMTP id 4so3582653gyh.31 for ; Tue, 20 Apr 2010 18:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Xwl8lGnmbypd3uIuFKUqzy0ix2b439zeX3S6OsaEcMQ=; b=A8rNgfcE27oNa43NemitSz+TOwFlpcx92PaBflhkqWXK2PQuDwFydOoXFMCCTCqCb9 Cl3lWnQIqRK8PybkxF8y/U/zzUpbNaIxrLfaK//epWnG13I/XtHlNGGsK1/q8dwQsAuy RvabUq27vuaPhZ27dnurL2n4MDkWSCzz9Cm4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QB9urolgsTQpgSkVFqyMxjznVQJcNSl9saxnfpnHeHhkDjT8UvBDWpSaEDP0/8TMKY MHfFOS3vtb35QMHFAVLHGIVBCsA2nYskNRpUoGBUSpt4L3c1kbaBHDKAeyVAQqv+EHBk sduIDs0hpSlYsRAwd5S4UJ+Sm7Vkog6xY/ovA= Received: by 10.101.131.4 with SMTP id i4mr11930783ann.174.1271814619739; Tue, 20 Apr 2010 18:50:19 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-126-141-37.dsl.scrm01.pacbell.net [68.126.141.37]) by mx.google.com with ESMTPS id b10sm62741201ana.6.2010.04.20.18.50.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 18:50:18 -0700 (PDT) Message-ID: <4BCE5D4F.2020707@gmail.com> Date: Tue, 20 Apr 2010 19:05:03 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: Joshua Bell References: <4BCE43ED.2040402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Follow-up from "What's *not* in VWRAP" presentation X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 01:50:40 -0000 Joshua Bell wrote: > On Tue, Apr 20, 2010 at 5:16 PM, Dzonatas Sol wrote: > >> I think what was proposed by "What's *not* in VWRAP" is to establish a >> default capability-to-scheme map, which would vwrap implementation to >> proceed without full flexibility of other possible schemes per capability. >> > > Jeepers, I hope not! > > In a nutshell, the presentation said: > Thanks for the clarification. I was a bit confused. (As I missed to type "which would allow a vwrap impl...", my bad.) > * Maybe, if they do need to be standardized, the minimum necessary for > interop might be e.g. as URLs pointing at human-readable Web pages - > e.g. when connecting to a world you could be given a mapping of > {'search': 'http://search.thisvirtualworld.org', 'map': > 'http://map.thisvirtualworld.org' } or some such. I dunno. > This is the basic idea behind ihave/sendme. I think others were concerned about extensibility on this idea when they heard "minimum," and I think that concern confused me a bit with their reaction. If I didn't apply the use-case of 2 separate programs on the client end (as with SNOW-375) that talked to a single server then I probably would worry more about extensibility then the 'minimum.' Between a single client program and a single server there are many assumptions that can be made, and those assumptions can include extensibility (which was demanded). With two programs on the client side, one might be 'extensible' and the other might not be. My concern centered on what would need to be the greatest set or the least common capabilities in such use-case. One program can handle the inventory while the other can handle the scene, for example. Right now, SNOW-375 expects a single peer, and that peer has an option to message with other peer programs, so there could be even more programs, like another for the world map, etc. A peer program may want to tell the viewer that a capability is actually a plugin to the viewer rather than being routed to through SNOW-375. That plugin then may message the peer directly rather than go through SNOW-375 (being routed through the viewer). I know this possibility has been talked about, yet I haven't seen other potential implementations mentioned yet in order to show there was significant consider of "minimums." Where I am at today with SNOW-375 has this potential with its flexibility of being peer-agnostic. I think in this use-case, the web-page you idealize above is/could-be actually handled by the peer program(s). > * So... don't assume XYZ will be done the same way that LLLP does it, > or that XYZ even needs to be in VWRAP > Currently, the peer program(s) just route everything through the viewer to figure out which path is needed between capabilities and LLLP. > * But if you believe that XYZ *is* necessary to specify for interop > and should be part of VWRAP, then the onus is on you to advocate for > it by writing specifications and providing implementations! > > There was also an aside in the presentation that pointed out that > VWRAP will require transport(s) with a variety of characteristics > (reliable/RESTful, reliable/streaming, unrealiable/streaming) and that > investigation needs to be done, as is called out in the WG charter. > There is an obvious (and actually needed) potential to not route everything through the viewer either for performance reasons or just because the scene renderer really doesn't need to process unrelated scene information. I understand this was some of the initial motive on the server side, so that a sim doesn't have to process everything unrelated to its scene, yet it can let it's peer programs do the work by capabilities (with a more direct connection to the viewer). I think a part of the design and implementation that founded vwrap has relied on a many-to-one relationship with lldp/capabilities-to-viewer, respectively. Now the "minimum" requires a more many-to-many relationship, where the server needs to know the capabilities of the client-peer programs, like how the viewer needed to know the capabilities of the server-peer programs. As I listened to the general conversation, others seemed to understand the modularity, yet some thought that any mention of many-to-many/server-to-client relationships meant support of a specific UI or for vwrap to support a specific UI, yet we know vwrap is about what needed to get that information to-and-from the specific UI, and it is not about the UI itself. (We, likewise, wouldn't want to say that a working implementation of vwrap on a certain sim isn't actually about the sim itself.) One of the needed performances is movement-input and related animated feedback. The performance I have noticed so far requires an optimal route for this particular dance, which means a specific capability and scheme. Reliable/RESTful is optimal enough for this basic set, yet as it is currently being routed through the scene renderer it has the potential to delay noticeably. In another example, mouse-events/look-at-xyz would be overkill for a RESTful messages and would need more of a unreliable stream to preform smoothly. It could route the stream through the viewer with a udp scheme/capability, yet it would be more wise to have the viewer just tell the peer program to route the peer's mouse-event/look-at-xyz stream more directly to the sim/server. Of course, another possibility is to have the scene renderer route everything as a peer through a main client program (that handles mouse-events) rather then the other way around. Either way, the main client program acts a proxy to the rest of the peer programs and/or plugins under the many-to-many "minimum." In short, the proxy may just want to tell the peers to "do-it-yourself" and pass them the uri to do just that. From dwl@us.ibm.com Tue Apr 27 14:42:16 2010 Return-Path: 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 E20B13A696E for ; Tue, 27 Apr 2010 14:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_80=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 oEGF1MMtvUYT for ; Tue, 27 Apr 2010 14:42:15 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 744803A6920 for ; Tue, 27 Apr 2010 14:42:15 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3RLarNJ021522 for ; Tue, 27 Apr 2010 17:36:53 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3RLg1r21773632 for ; Tue, 27 Apr 2010 17:42:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3RLg1Sr023107 for ; Tue, 27 Apr 2010 17:42:01 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3RLg1ee023096 for ; Tue, 27 Apr 2010 17:42:01 -0400 To: vwrap@ietf.org MIME-Version: 1.0 X-KeepSent: 12BB21F8:3FAB95C0-85257712:0076D115; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 27 Apr 2010 17:41:55 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/27/2010 17:42:01, Serialize complete at 04/27/2010 17:42:01 Content-Type: multipart/alternative; boundary="=_alternative 0077320F85257712_=" Subject: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 21:42:17 -0000 This is a multipart message in MIME format. --=_alternative 0077320F85257712_= Content-Type: text/plain; charset="US-ASCII" As always, food for thought, probably partly baked. Josh Linden's presentation on the Linden Legacy Protocol raises the possibility that a substantial number of operations currently managed by the Linden Labs client be viewed as "out of scope" for VWRAP and exposed as "there is a URI/URL which provides access to a service to perform this task." Thus rather than including a set of LLIDL messages which define how to set parcel permissions, you would associate a "Here is a URI to invoke to get to a UI about this parcel" I would argue this solves roughly 1/3 of the problem. It makes it very easy for a deployed to provide a customer user interface, and it nicely reduces the amount of work needed to describe a useful protocol. I also said 1/3 because I think it misses two things. First, it begs the question(s) "What cues are needed to let the client know where things happen" and second, it misses the need to expose the attributes these interfaces would manage in a programmatic fashion. Effectively, the first problem is one of asking "How do we overlay the scene graph with UI cues." The more I think about it, the more I like the idea of solving this problem elegantly. In particular, the obvious design "This portion of the scenegraph or this broad area of virtual space" has "This URI" to invoke for more information seems pretty straightforward. How to cue things like "parcel boundaries" and "Has this property" is a little less obvious, but a good solution would be well worth having. Notice that this also allows some potentially elegant integration points. One could expose custom web page UIs as associated with Vendors, Buildings, portions of the ground, or any part of the scenegraph. The second problem is also one worth solving, tho its more difficult. I think it falls into two or three parts. The easy bit, is again, the "cue" issue. In short, how does one find out that there *is* structured data or an API associated with some portion of virtual space. At one level, the temptation is to say the web solves this already, and blend it in with an overall scheme for associating URIs with each bit of virtual space or virtual item. I'm not sure this is sufficient, but I think it serves as a nice starting point. I think a small worked example would be helpful. This is intended to be fairly accurate, but clearly not more than a thought experiment. Posit a virtual space which wishes to expose an administrative interface which permits visitors with proper permission to change several parameters of the physics engine. The current model of things would require a cap and a custom bit of user interface, or user interface exposed via some "in world" hook, such as a prim exposing a web page, or a web page entirely disjoint from the inworld experience. Instead, we would provide a way for the region to advertize the existence of the service to the client. I am, for example, imagining either a capability exposed by the region, or a public URI/URL exposed by the client. (Whether the approach is fully web centric, or blended in with VWRAP style of capability access is clearly something worthy of discussion) The client, on arrival to the region, fetches the URI, using content negotiation and gets back a "cue" to display to the user that a service is available. (Content negotiation let web based internationalization and such simply happens) The cue is presented to the user as the client sees fit, and if it is invoked, an associated URI launches the user interface web service, which can be pre-fed with context, based on the user. Now, this is doubly inappropriate for a programmatic approach. We neither want to make programs screen scrape for content cues, nor do we want to present them with a nice pretty user interface to manipulate. Thus, a structured data path would be desirable. More on thinking about how regions and scenegraph can expose APIs for performing tasks in a future post - David ~ Zha --=_alternative 0077320F85257712_= Content-Type: text/html; charset="US-ASCII"
As always, food for thought, probably partly baked.

Josh Linden's presentation on the Linden Legacy Protocol
raises the possibility that a substantial number of
operations currently managed by the Linden Labs client be
viewed as "out of scope" for VWRAP and exposed as "there is
a URI/URL which provides access to a service to perform this
task."

Thus rather than including a set of LLIDL messages which define
how to set parcel permissions, you would associate a "Here is a
URI to invoke to get to a UI about this parcel"

I would argue this solves roughly 1/3 of the problem. It makes it very
easy for a deployed to provide a customer user interface, and it nicely
reduces the amount of work needed to describe a useful protocol. I also
said 1/3 because I think it misses two things. First, it begs the
question(s) "What cues are needed to let the client know where things
happen" and second, it misses the need to expose the attributes these
interfaces would manage in a programmatic fashion.

Effectively, the first problem is one of asking "How do we overlay the
scene graph with UI cues." The more I think about it, the more I like
the idea of solving this problem elegantly. In particular, the obvious
design "This portion of the scenegraph or this broad area of virtual
space" has "This URI" to invoke for more information seems pretty
straightforward. How to cue things like "parcel boundaries" and "Has this
property" is a little less obvious, but a good solution would be well
worth having. Notice that this also allows some potentially elegant
integration points. One could expose custom web page UIs as associated
with Vendors, Buildings, portions of the ground, or any part of the
scenegraph.

The second problem is also one worth solving, tho its more difficult.
I think it falls into two or three parts. The easy bit, is again, the
"cue" issue. In short, how does one find out that there *is* structured
data or an API associated with some portion of virtual space. At one
level, the temptation is to say the web solves this already, and blend
it in with an overall scheme for associating URIs with each bit of
virtual space or virtual item. I'm not sure this is sufficient, but I
think it serves as a nice starting point.

I think a small worked example would be helpful. This is intended to be
fairly accurate, but clearly not more than a thought experiment.

Posit a virtual space which wishes to expose an administrative
interface which permits visitors with proper permission to change
several parameters of the physics engine. The current model of things
would require a cap and a custom bit of user interface, or user
interface exposed via some "in world" hook, such as a prim exposing a
web page, or a web page entirely disjoint from the inworld experience.

Instead, we would provide a way for the region to advertize the
existence of the service to the client. I am, for example, imagining
either a capability exposed by the region, or a public URI/URL exposed by
the client. (Whether the approach is fully web centric, or blended in
with VWRAP style of capability access is clearly something worthy of
discussion)  

The client, on arrival to the region, fetches the URI, using content
negotiation and gets back a "cue" to display to the user that a service
is available. (Content negotiation let web based internationalization
and such simply happens) The cue is presented to the user as the client
sees fit, and if it is invoked, an associated URI launches the
user interface web service, which can be pre-fed with context, based
on the user.

Now, this is doubly inappropriate for a programmatic approach. We neither
want to make programs screen scrape for content cues, nor do we want to
present them with a nice pretty user interface to manipulate. Thus,
a structured data path would be desirable. More on thinking about how
regions and scenegraph can expose APIs for performing tasks in a future post

- David
~ Zha
--=_alternative 0077320F85257712_=-- From lenglish5@cox.net Tue Apr 27 15:23:48 2010 Return-Path: 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 9E77D3A6AAD for ; Tue, 27 Apr 2010 15:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_60=1] 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 AnY1c9-pA3sD for ; Tue, 27 Apr 2010 15:23:47 -0700 (PDT) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id D02F33A68F1 for ; Tue, 27 Apr 2010 15:23:40 -0700 (PDT) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao106.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100427222328.GLQT1296.fed1rmmtao106.cox.net@fed1rmimpo03.cox.net>; Tue, 27 Apr 2010 18:23:28 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id AmPU1e0082l1Ksg04mPUm0; Tue, 27 Apr 2010 18:23:28 -0400 X-VR-Score: -100.00 X-Authority-Analysis: v=1.1 cv=b4II0uhcJPnwjva2/FqJSYAtAoopJitAe4Ogu0tU6w4= c=1 sm=1 a=r8JTnP1grp0A:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=iZBsntirAOaFN-kG9QkA:9 a=W7KGIxZVDiRyRThyTH8A:7 a=eDj0-F5kDjAJ3SCZ099Igvx3YpMA:4 a=wPNLvfGTeEIA:10 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Message-ID: <4BD763E0.7020907@cox.net> Date: Tue, 27 Apr 2010 15:23:28 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: David W Levine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:23:48 -0000 David W Levine wrote: > [...] > > The client, on arrival to the region, fetches the URI, using content > negotiation and gets back a "cue" to display to the user that a service > is available. (Content negotiation let web based internationalization > and such simply happens) The cue is presented to the user as the client > sees fit, and if it is invoked, an associated URI launches the > user interface web service, which can be pre-fed with context, based > on the user. > > Now, this is doubly inappropriate for a programmatic approach. We neither > want to make programs screen scrape for content cues, nor do we want to > present them with a nice pretty user interface to manipulate. Thus, > a structured data path would be desirable. More on thinking about how > regions and scenegraph can expose APIs for performing tasks in a > future post Goes back to the AppleEvents/AppleScript model of having predefined suites of actions (programming-actions as well as user, in this case), plus the ability to provide "dictionaries" for custom actions and parameters that they accept. There's plenty of available models for how this could work (at a less user-oriented manner) in languages with introspection. We just need to adopt a plain-text variant (no hash codes and such). Lawson From john.hurliman@intel.com Wed Apr 28 08:41:25 2010 Return-Path: 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 1A6833A6B61 for ; Wed, 28 Apr 2010 08:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 eBLfRBDCW0DS for ; Wed, 28 Apr 2010 08:41:24 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 23E613A6C17 for ; Wed, 28 Apr 2010 08:39:29 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Apr 2010 08:37:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,288,1270450800"; d="scan'208";a="617216582" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga001.jf.intel.com with ESMTP; 28 Apr 2010 08:39:03 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Apr 2010 09:39:13 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 28 Apr 2010 09:39:13 -0600 From: "Hurliman, John" To: David W Levine Date: Wed, 28 Apr 2010 09:39:06 -0600 Thread-Topic: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion Thread-Index: Acrm6PLwh/jGrDcpS2eSM/gHZpZRCg== Message-ID: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 15:41:25 -0000 RG9lcyB0aGUgbWV0aG9kIGZvciBleHBvc2luZyBhbiBBUEkgbmVlZCB0byBiZSBkaWZmZXJlbnQg ZnJvbSB0aGUgbWV0aG9kIHRoYXQgZXhwb3NlcyBhIHVzZXIgaW50ZXJmYWNlPw0KDQpKb2huDQoN Ck9uIEFwciAyNywgMjAxMCwgYXQgMjo0MiBQTSwgIkRhdmlkIFcgTGV2aW5lIiA8ZHdsQHVzLmli bS5jb208bWFpbHRvOmR3bEB1cy5pYm0uY29tPj4gd3JvdGU6DQoNCg0KQXMgYWx3YXlzLCBmb29k IGZvciB0aG91Z2h0LCBwcm9iYWJseSBwYXJ0bHkgYmFrZWQuDQoNCkpvc2ggTGluZGVuJ3MgcHJl c2VudGF0aW9uIG9uIHRoZSBMaW5kZW4gTGVnYWN5IFByb3RvY29sDQpyYWlzZXMgdGhlIHBvc3Np YmlsaXR5IHRoYXQgYSBzdWJzdGFudGlhbCBudW1iZXIgb2YNCm9wZXJhdGlvbnMgY3VycmVudGx5 IG1hbmFnZWQgYnkgdGhlIExpbmRlbiBMYWJzIGNsaWVudCBiZQ0Kdmlld2VkIGFzICJvdXQgb2Yg c2NvcGUiIGZvciBWV1JBUCBhbmQgZXhwb3NlZCBhcyAidGhlcmUgaXMNCmEgVVJJL1VSTCB3aGlj aCBwcm92aWRlcyBhY2Nlc3MgdG8gYSBzZXJ2aWNlIHRvIHBlcmZvcm0gdGhpcw0KdGFzay4iDQoN ClRodXMgcmF0aGVyIHRoYW4gaW5jbHVkaW5nIGEgc2V0IG9mIExMSURMIG1lc3NhZ2VzIHdoaWNo IGRlZmluZQ0KaG93IHRvIHNldCBwYXJjZWwgcGVybWlzc2lvbnMsIHlvdSB3b3VsZCBhc3NvY2lh dGUgYSAiSGVyZSBpcyBhDQpVUkkgdG8gaW52b2tlIHRvIGdldCB0byBhIFVJIGFib3V0IHRoaXMg cGFyY2VsIg0KDQpJIHdvdWxkIGFyZ3VlIHRoaXMgc29sdmVzIHJvdWdobHkgMS8zIG9mIHRoZSBw cm9ibGVtLiBJdCBtYWtlcyBpdCB2ZXJ5DQplYXN5IGZvciBhIGRlcGxveWVkIHRvIHByb3ZpZGUg YSBjdXN0b21lciB1c2VyIGludGVyZmFjZSwgYW5kIGl0IG5pY2VseQ0KcmVkdWNlcyB0aGUgYW1v dW50IG9mIHdvcmsgbmVlZGVkIHRvIGRlc2NyaWJlIGEgdXNlZnVsIHByb3RvY29sLiBJIGFsc28N CnNhaWQgMS8zIGJlY2F1c2UgSSB0aGluayBpdCBtaXNzZXMgdHdvIHRoaW5ncy4gRmlyc3QsIGl0 IGJlZ3MgdGhlDQpxdWVzdGlvbihzKSAiV2hhdCBjdWVzIGFyZSBuZWVkZWQgdG8gbGV0IHRoZSBj bGllbnQga25vdyB3aGVyZSB0aGluZ3MNCmhhcHBlbiIgYW5kIHNlY29uZCwgaXQgbWlzc2VzIHRo ZSBuZWVkIHRvIGV4cG9zZSB0aGUgYXR0cmlidXRlcyB0aGVzZQ0KaW50ZXJmYWNlcyB3b3VsZCBt YW5hZ2UgaW4gYSBwcm9ncmFtbWF0aWMgZmFzaGlvbi4NCg0KRWZmZWN0aXZlbHksIHRoZSBmaXJz dCBwcm9ibGVtIGlzIG9uZSBvZiBhc2tpbmcgIkhvdyBkbyB3ZSBvdmVybGF5IHRoZQ0Kc2NlbmUg Z3JhcGggd2l0aCBVSSBjdWVzLiIgVGhlIG1vcmUgSSB0aGluayBhYm91dCBpdCwgdGhlIG1vcmUg SSBsaWtlDQp0aGUgaWRlYSBvZiBzb2x2aW5nIHRoaXMgcHJvYmxlbSBlbGVnYW50bHkuIEluIHBh cnRpY3VsYXIsIHRoZSBvYnZpb3VzDQpkZXNpZ24gIlRoaXMgcG9ydGlvbiBvZiB0aGUgc2NlbmVn cmFwaCBvciB0aGlzIGJyb2FkIGFyZWEgb2YgdmlydHVhbA0Kc3BhY2UiIGhhcyAiVGhpcyBVUkki IHRvIGludm9rZSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBzZWVtcyBwcmV0dHkNCnN0cmFpZ2h0Zm9y d2FyZC4gSG93IHRvIGN1ZSB0aGluZ3MgbGlrZSAicGFyY2VsIGJvdW5kYXJpZXMiIGFuZCAiSGFz IHRoaXMNCnByb3BlcnR5IiBpcyBhIGxpdHRsZSBsZXNzIG9idmlvdXMsIGJ1dCBhIGdvb2Qgc29s dXRpb24gd291bGQgYmUgd2VsbA0Kd29ydGggaGF2aW5nLiBOb3RpY2UgdGhhdCB0aGlzIGFsc28g YWxsb3dzIHNvbWUgcG90ZW50aWFsbHkgZWxlZ2FudA0KaW50ZWdyYXRpb24gcG9pbnRzLiBPbmUg Y291bGQgZXhwb3NlIGN1c3RvbSB3ZWIgcGFnZSBVSXMgYXMgYXNzb2NpYXRlZA0Kd2l0aCBWZW5k b3JzLCBCdWlsZGluZ3MsIHBvcnRpb25zIG9mIHRoZSBncm91bmQsIG9yIGFueSBwYXJ0IG9mIHRo ZQ0Kc2NlbmVncmFwaC4NCg0KVGhlIHNlY29uZCBwcm9ibGVtIGlzIGFsc28gb25lIHdvcnRoIHNv bHZpbmcsIHRobyBpdHMgbW9yZSBkaWZmaWN1bHQuDQpJIHRoaW5rIGl0IGZhbGxzIGludG8gdHdv IG9yIHRocmVlIHBhcnRzLiBUaGUgZWFzeSBiaXQsIGlzIGFnYWluLCB0aGUNCiJjdWUiIGlzc3Vl LiBJbiBzaG9ydCwgaG93IGRvZXMgb25lIGZpbmQgb3V0IHRoYXQgdGhlcmUgKmlzKiBzdHJ1Y3R1 cmVkDQpkYXRhIG9yIGFuIEFQSSBhc3NvY2lhdGVkIHdpdGggc29tZSBwb3J0aW9uIG9mIHZpcnR1 YWwgc3BhY2UuIEF0IG9uZQ0KbGV2ZWwsIHRoZSB0ZW1wdGF0aW9uIGlzIHRvIHNheSB0aGUgd2Vi IHNvbHZlcyB0aGlzIGFscmVhZHksIGFuZCBibGVuZA0KaXQgaW4gd2l0aCBhbiBvdmVyYWxsIHNj aGVtZSBmb3IgYXNzb2NpYXRpbmcgVVJJcyB3aXRoIGVhY2ggYml0IG9mDQp2aXJ0dWFsIHNwYWNl IG9yIHZpcnR1YWwgaXRlbS4gSSdtIG5vdCBzdXJlIHRoaXMgaXMgc3VmZmljaWVudCwgYnV0IEkN CnRoaW5rIGl0IHNlcnZlcyBhcyBhIG5pY2Ugc3RhcnRpbmcgcG9pbnQuDQoNCkkgdGhpbmsgYSBz bWFsbCB3b3JrZWQgZXhhbXBsZSB3b3VsZCBiZSBoZWxwZnVsLiBUaGlzIGlzIGludGVuZGVkIHRv IGJlDQpmYWlybHkgYWNjdXJhdGUsIGJ1dCBjbGVhcmx5IG5vdCBtb3JlIHRoYW4gYSB0aG91Z2h0 IGV4cGVyaW1lbnQuDQoNClBvc2l0IGEgdmlydHVhbCBzcGFjZSB3aGljaCB3aXNoZXMgdG8gZXhw b3NlIGFuIGFkbWluaXN0cmF0aXZlDQppbnRlcmZhY2Ugd2hpY2ggcGVybWl0cyB2aXNpdG9ycyB3 aXRoIHByb3BlciBwZXJtaXNzaW9uIHRvIGNoYW5nZQ0Kc2V2ZXJhbCBwYXJhbWV0ZXJzIG9mIHRo ZSBwaHlzaWNzIGVuZ2luZS4gVGhlIGN1cnJlbnQgbW9kZWwgb2YgdGhpbmdzDQp3b3VsZCByZXF1 aXJlIGEgY2FwIGFuZCBhIGN1c3RvbSBiaXQgb2YgdXNlciBpbnRlcmZhY2UsIG9yIHVzZXINCmlu dGVyZmFjZSBleHBvc2VkIHZpYSBzb21lICJpbiB3b3JsZCIgaG9vaywgc3VjaCBhcyBhIHByaW0g ZXhwb3NpbmcgYQ0Kd2ViIHBhZ2UsIG9yIGEgd2ViIHBhZ2UgZW50aXJlbHkgZGlzam9pbnQgZnJv bSB0aGUgaW53b3JsZCBleHBlcmllbmNlLg0KDQpJbnN0ZWFkLCB3ZSB3b3VsZCBwcm92aWRlIGEg d2F5IGZvciB0aGUgcmVnaW9uIHRvIGFkdmVydGl6ZSB0aGUNCmV4aXN0ZW5jZSBvZiB0aGUgc2Vy dmljZSB0byB0aGUgY2xpZW50LiBJIGFtLCBmb3IgZXhhbXBsZSwgaW1hZ2luaW5nDQplaXRoZXIg YSBjYXBhYmlsaXR5IGV4cG9zZWQgYnkgdGhlIHJlZ2lvbiwgb3IgYSBwdWJsaWMgVVJJL1VSTCBl eHBvc2VkIGJ5DQp0aGUgY2xpZW50LiAoV2hldGhlciB0aGUgYXBwcm9hY2ggaXMgZnVsbHkgd2Vi IGNlbnRyaWMsIG9yIGJsZW5kZWQgaW4NCndpdGggVldSQVAgc3R5bGUgb2YgY2FwYWJpbGl0eSBh Y2Nlc3MgaXMgY2xlYXJseSBzb21ldGhpbmcgd29ydGh5IG9mDQpkaXNjdXNzaW9uKQ0KDQpUaGUg Y2xpZW50LCBvbiBhcnJpdmFsIHRvIHRoZSByZWdpb24sIGZldGNoZXMgdGhlIFVSSSwgdXNpbmcg Y29udGVudA0KbmVnb3RpYXRpb24gYW5kIGdldHMgYmFjayBhICJjdWUiIHRvIGRpc3BsYXkgdG8g dGhlIHVzZXIgdGhhdCBhIHNlcnZpY2UNCmlzIGF2YWlsYWJsZS4gKENvbnRlbnQgbmVnb3RpYXRp b24gbGV0IHdlYiBiYXNlZCBpbnRlcm5hdGlvbmFsaXphdGlvbg0KYW5kIHN1Y2ggc2ltcGx5IGhh cHBlbnMpIFRoZSBjdWUgaXMgcHJlc2VudGVkIHRvIHRoZSB1c2VyIGFzIHRoZSBjbGllbnQNCnNl ZXMgZml0LCBhbmQgaWYgaXQgaXMgaW52b2tlZCwgYW4gYXNzb2NpYXRlZCBVUkkgbGF1bmNoZXMg dGhlDQp1c2VyIGludGVyZmFjZSB3ZWIgc2VydmljZSwgd2hpY2ggY2FuIGJlIHByZS1mZWQgd2l0 aCBjb250ZXh0LCBiYXNlZA0Kb24gdGhlIHVzZXIuDQoNCk5vdywgdGhpcyBpcyBkb3VibHkgaW5h cHByb3ByaWF0ZSBmb3IgYSBwcm9ncmFtbWF0aWMgYXBwcm9hY2guIFdlIG5laXRoZXINCndhbnQg dG8gbWFrZSBwcm9ncmFtcyBzY3JlZW4gc2NyYXBlIGZvciBjb250ZW50IGN1ZXMsIG5vciBkbyB3 ZSB3YW50IHRvDQpwcmVzZW50IHRoZW0gd2l0aCBhIG5pY2UgcHJldHR5IHVzZXIgaW50ZXJmYWNl IHRvIG1hbmlwdWxhdGUuIFRodXMsDQphIHN0cnVjdHVyZWQgZGF0YSBwYXRoIHdvdWxkIGJlIGRl c2lyYWJsZS4gTW9yZSBvbiB0aGlua2luZyBhYm91dCBob3cNCnJlZ2lvbnMgYW5kIHNjZW5lZ3Jh cGggY2FuIGV4cG9zZSBBUElzIGZvciBwZXJmb3JtaW5nIHRhc2tzIGluIGEgZnV0dXJlIHBvc3QN Cg0KLSBEYXZpZA0KfiBaaGENCg== From newhook@us.ibm.com Wed Apr 28 09:09:46 2010 Return-Path: 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 B1E673A6B8F; Wed, 28 Apr 2010 09:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 oNsCzVRlE25r; Wed, 28 Apr 2010 09:09:44 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 1F0BA3A6B61; Wed, 28 Apr 2010 09:09:01 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3SG3T8G005265; Wed, 28 Apr 2010 12:03:29 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3SG8ci3142456; Wed, 28 Apr 2010 12:08:38 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3SG8YiK012368; Wed, 28 Apr 2010 10:08:35 -0600 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3SG8XTV012306; Wed, 28 Apr 2010 10:08:34 -0600 In-Reply-To: References: X-KeepSent: BDA49144:264FC5E2-85257713:004EBC6A; type=4; name=$KeepSent To: vwrap@ietf.org, vwrap-bounces@ietf.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Richard Newhook Date: Wed, 28 Apr 2010 12:05:05 -0400 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/28/2010 10:08:34 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFD80DFDD3AFA8f9e8a93df938690918c0ABBFD80DFDD3AFA" Content-Disposition: inline Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 16:09:47 -0000 --0__=0ABBFD80DFDD3AFA8f9e8a93df938690918c0ABBFD80DFDD3AFA Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable David Levine wrote on 04/27/2010 05:41:55 PM: > Now, this is doubly inappropriate for a programmatic approach. We nei= ther > want to make programs screen scrape for content cues, nor do we want = to > present them with a nice pretty user interface to manipulate. Thus, > a structured data path would be desirable. More on thinking about how= > regions and scenegraph can expose APIs for performing tasks in a futu= re post I'd like to add some extra detail here to help explain the weaknesse= s to using this approach a little more. While it's tempting to feel that a prepackaged UI component would eliminate a significant portion of complexity, it makes some strong assumptions about the circumstances un= der which it will be applied: capabilities of the consuming endpoint, representational restrictions, etc. The effect of each assumption that= we add is that we become more tightly tied to that exact situation describ= ed by the assumptions, and more burdensome to those situations outside the= assumptions in order to integrate with us. One of the assumptions of the prepackaged UI approach that carries = a heavy burden is that the consumer of the service is a human. Ultimatel= y that may be true, but the human part of the whole system is little more= than the tip of the proverbial iceberg. If you look at most virtual worlds, the human-to-computer interface (a.k.a "the client") is only a small portion of the total infrastructure. The rest consists largely o= f back-end services and systems that keep the world 'turning'. For examp= le (the quintessential SL world), there's presence services, money transactions services, region simulators, message routing, backup servi= ces, network monitoring....and untold many more. These are the major consum= ers of VW data, and practically none of them will benefit from a prepackage= d UI component. If anything, the burden of having to untangle the data from= the UI will be a significant impairment to these services. The prepackaged UI component itself poses some assumptions that are,= quite frankly, unreliable at best. It is conceivable that some implementations of virtual worlds may not have a standard HTML renderin= g component. For example, mobile devices with extremely constrained disp= lay sizes. Or virtual worlds targeting the blind. Or systems that act on behalf of the user in a semi-autonomous fashion. In other words, we'll= end up restricting the usefulness to a very specific set of circumstances, = or eventually see it mutating into a monster in the attempt of making it useful to all circumstances. It'll also break the immersiveness/cohesiveness of third-party clien= t implementations, or it will affect the look/feel (think: other VW's log= o embedded in your own client), or it'll introduce a new security attack vector into the client, etc etc etc. You get the point. Perhaps, then, what we would do is approach the issue from a differe= nt angle, one that permits the assumptions to be optional. For example, each service would provide the following: 1) A definition of the service call, describing the methods, fields = and validation rules required. Some of this is already in common use, via = XML, DTD. 2) The service itself to perform the actions. For example, SOAP or = WSDL services, JSON-based calls, etc. 3) A working implementation of the service in HTML form (the prior-mentioned UI component) that can be displayed and used directly. = Can also be used as a living example of how to make use of 1) and 2) in a functional implementation. This type of approach would both give an easy-out escape for those clients that do not wish to deal with the messy details of the service,= while still accommodating those clients that have a need to get down in= the weeds of the service. Thoughts? Richard/ Newfie Pendragon (SL)= --0__=0ABBFD80DFDD3AFA8f9e8a93df938690918c0ABBFD80DFDD3AFA Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

David Levine wrote on 04/27/2010 05:41:55 PM:

> Now, this is doubly inappropriate for a programmatic approach. We = neither
> want to make programs screen scrape for content cues, nor do we wa= nt to
> present them with a nice pretty user interface to manipulate. Thus= ,
> a structured data path would be desirable. More on thinking about = how
> regions and scenegraph can expose APIs for performing tasks in a f= uture post

I'd like to add some extra detail here to help explain the weakness= es to using this approach a little more.  While it's tempting to f= eel that a prepackaged UI component would eliminate a significant porti= on of complexity, it makes some strong assumptions about the circumstan= ces under which it will be applied: capabilities of the consuming endpo= int, representational restrictions, etc.  The effect of each assum= ption that we add is that we become more tightly tied to that exact sit= uation described by the assumptions, and more burdensome to those situa= tions outside the assumptions in order to integrate with us.

 One of the assumptions of the prepackaged UI approach that ca= rries a heavy burden is that the consumer of the service is a human. &n= bsp;Ultimately that may be true, but the human part of the whole system= is little more than the tip of the proverbial iceberg.  If you lo= ok at most virtual worlds, the human-to-computer interface (a.k.a "= ;the client") is only a small portion of the total infrastructure.=  The rest consists largely of back-end services and systems that = keep the world 'turning'.  For example (the quintessential SL worl= d), there's presence services, money transactions services, region simu= lators, message routing, backup services, network monitoring....and unt= old many more.  These are the major consumers of VW data, and prac= tically none of them will benefit from a prepackaged UI component. &nbs= p;If anything, the burden of having to untangle the data from the UI wi= ll be a significant impairment to these services.

The prepackaged UI component itself poses some assumptions that are= , quite frankly, unreliable at best.  It is conceivable that some = implementations of virtual worlds may not have a standard HTML renderin= g component.  For example, mobile devices with extremely constrain= ed display sizes.  Or virtual worlds targeting the blind.  Or= systems that act on behalf of the user in a semi-autonomous fashion. &= nbsp;In other words, we'll end up restricting the usefulness to a very = specific set of circumstances, or eventually see it mutating into a mon= ster in the attempt of making it useful to all circumstances.

It'll also break the immersiveness/cohesiveness of third-party clie= nt implementations, or it will affect the look/feel (think: other VW's = logo embedded in your own client), or it'll introduce a new security at= tack vector into the client, etc etc etc.  You get the point.=

Perhaps, then, what we would do is approach the issue from a differ= ent angle, one that permits the assumptions to be optional.

For example, each service would provide the following:
1) A definition of the service call, describing the methods, fields= and validation rules required.  Some of this is already in common= use, via XML, DTD.
2) The service itself to perform the actions.  For example, SO= AP or WSDL services, JSON-based calls, etc.
3) A working implementation of the service in HTML form (the prior-= mentioned UI component) that can be displayed and used directly.  = Can also be used as a living example of how to make use of 1) and 2) in= a functional implementation.

This type of approach would both give an easy-out escape for those = clients that do not wish to deal with the messy details of the service,= while still accommodating those clients that have a need to get down i= n the weeds of the service.


Thoughts?



Richard/
Newfie Pendragon (SL)= --0__=0ABBFD80DFDD3AFA8f9e8a93df938690918c0ABBFD80DFDD3AFA-- From dwl@us.ibm.com Wed Apr 28 09:14:29 2010 Return-Path: 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 2837C3A6B54 for ; Wed, 28 Apr 2010 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cbs0qz-bO+j7 for ; Wed, 28 Apr 2010 09:14:28 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id B9E443A6B21 for ; Wed, 28 Apr 2010 09:14:25 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3SG1k2j032080 for ; Wed, 28 Apr 2010 12:01:46 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3SGECCY165882 for ; Wed, 28 Apr 2010 12:14:12 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3SGEBAp016034 for ; Wed, 28 Apr 2010 13:14:11 -0300 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3SGEBDC016028; Wed, 28 Apr 2010 13:14:11 -0300 In-Reply-To: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> References: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> To: "Hurliman, John" MIME-Version: 1.0 X-KeepSent: 3E7A4FA5:8A889E67-85257713:0056A958; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Wed, 28 Apr 2010 12:14:11 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/28/2010 12:14:11, Serialize complete at 04/28/2010 12:14:11 Content-Type: multipart/alternative; boundary="=_alternative 005930A885257713_=" Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 16:14:29 -0000 This is a multipart message in MIME format. --=_alternative 005930A885257713_= Content-Type: text/plain; charset="US-ASCII" "Hurliman, John" wrote on 04/28/2010 11:39:06 AM: > [image removed] > > Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion > > Hurliman, John > > to: > > David W Levine > > 04/28/2010 11:40 AM > > Cc: > > "vwrap@ietf.org" > > Does the method for exposing an API need to be different from the > method that exposes a user interface? > > John > I've been giving that exact question some serious thought. One simple answer is to say, as we often do, "Content Negotiation Saves the day!" If you want the programatic api, ask for application/xml, if you want something to present to the user, ask for text/html. If one wants to be stronger, make the mime types more explicit. (I'm not thrilled with this because if we can reuse existing, obvious mime types, I tend to think its much better) But.. there are at least two things which make me go "maybe not." Part one is, well, contextual. Do we expose things primarily as part of the visual client centric scenegraph? If we tie things to closely to be "logged in" to a region and having a client, then we end up making it much harder for applications (and for that matter clients) which are substantially different than the current client. We get a lot of power by saying "This service/ui/api" is associated with "this portion of the scenegraph." in terms of the immersive user experience. But.. the same power gets in the way of web service like integration where one might well want to simply expose a URI that lets you directly manipulate things in a portion of the world. My current rough thinking is that if we do things correctly, we can expose the same API via both "web external" facing discovery and "scenegraph internal" facing discovery. If we let the UI/API be chosen by content negotiation, we may be done. (Tho, I'm not at all user exposing a UI will help much, as you'll likely not have enough context to do anything useful with it, but.. I can imagine clients which will) As I said. Very much partly baked thinking at the moment, ripe for discussion. - David ~ Zha > On Apr 27, 2010, at 2:42 PM, "David W Levine" mailto:dwl@us.ibm.com>> wrote: > > > As always, food for thought, probably partly baked. > > Josh Linden's presentation on the Linden Legacy Protocol [snip] --=_alternative 005930A885257713_= Content-Type: text/html; charset="US-ASCII"

"Hurliman, John" <john.hurliman@intel.com> wrote on 04/28/2010 11:39:06 AM:

> [image removed]
>
> Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion
>
> Hurliman, John
>
> to:
>
> David W Levine
>
> 04/28/2010 11:40 AM
>
> Cc:
>
> "vwrap@ietf.org"
>
> Does the method for exposing an API need to be different from the
> method that exposes a user interface?
>
> John
>

I've been giving that exact question some serious thought. One simple
answer is to say, as we often do, "Content Negotiation Saves the day!"
If you want the programatic api, ask for application/xml, if you want
something to present to the user, ask for text/html. If one wants to be
stronger, make the mime types more explicit. (I'm not thrilled with this
because if we can reuse existing, obvious mime types, I tend to think
its much better)

But.. there are at least two things which make me go "maybe not." Part
one is, well, contextual. Do we expose things primarily as part of the
visual client centric scenegraph? If we tie things to closely to be
"logged in" to a region and having a client, then we end up making it
much harder for applications (and for that matter clients) which are
substantially different than the current client. We get a lot of power
by saying "This service/ui/api" is associated with "this portion of the
scenegraph." in terms of the immersive user experience. But.. the same
power gets in the way of web service like integration where one might well
want to simply expose a URI that lets you directly manipulate things in
a portion of the world.

My current rough thinking is that if we do things correctly, we can expose
the same API via both "web external" facing discovery and
"scenegraph internal" facing discovery. If we let the UI/API be chosen
by content negotiation, we may be done. (Tho, I'm not at all user exposing
a UI will help much, as you'll likely not have enough context to do anything
useful with it, but.. I can imagine clients which will)

As I said. Very much partly baked thinking at the moment, ripe for discussion.

- David
~ Zha


> On Apr 27, 2010, at 2:42 PM, "David W Levine" <dwl@us.ibm.com<
> mailto:dwl@us.ibm.com>> wrote:
>
>
> As always, food for thought, probably partly baked.
>
> Josh Linden's presentation on the Linden Legacy Protocol
[snip] --=_alternative 005930A885257713_=-- From dzonatas@gmail.com Wed Apr 28 15:52:46 2010 Return-Path: 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 5FAE53A6A16 for ; Wed, 28 Apr 2010 15:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] 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 PAx4LiRouQjy for ; Wed, 28 Apr 2010 15:52:45 -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 565933A67D2 for ; Wed, 28 Apr 2010 15:52:41 -0700 (PDT) Received: by gyh4 with SMTP id 4so7721957gyh.31 for ; Wed, 28 Apr 2010 15:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XQ4m/MTmBxAU7ffhqysfpoO46mHh9LYK1QgUVFBhUBo=; b=jhsdbPuhuMY0ghdNEZLd3wpyDNnskV8tj28XKJ7a6zy0H8UH5cHGUdggQwVqeh7g1N KoD1s9B6hql9JMC2UtfpUi2wrha67/2Z4VHeeftIkSJuB9JjFckpdRvMpWT1Gs8KuHVj x4FsqZAC/IUW1fY96MLehd87RgOVkfdtsahm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bm5yGANKm+TCPqBTh5HGlybG9RGEX1NTsF+ntRMO42WzNO2AY7qnqcT5ChcAEge90U wG37el/f3oqx0ivk95AJJw+NOselecmSpclI3D9w1adCugBye86VqpB+iIB65GtUo2YG +r5JTNLfut5CDvV5lT5w9g8/iCd1/cKKjtI64= Received: by 10.101.176.9 with SMTP id d9mr3647174anp.66.1272495143545; Wed, 28 Apr 2010 15:52:23 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-126-141-37.dsl.scrm01.pacbell.net [68.126.141.37]) by mx.google.com with ESMTPS id 26sm2500660anx.3.2010.04.28.15.52.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Apr 2010 15:52:22 -0700 (PDT) Message-ID: <4BD8BFA4.8030101@gmail.com> Date: Wed, 28 Apr 2010 16:07:16 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: David W Levine References: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 22:52:46 -0000 David W Levine wrote: > > As I said. Very much partly baked thinking at the moment, ripe for > discussion. > > - David > ~ Zha > I looked around for a dictionary of resources for VWRAP, and it looks like there isn't a specific set given as the time of the e-mail. I read over the VWRAP docs and seen the pattern to follow. I heard there are some implementations, yet those implementations haven't really exposed a given set beyond the sources that already reveal the older OGPX implementation. I looked for the VWRAP resource dictionary in order to align SNOW-375 resources where ever they overlap. So far, SNOW-375 has these: https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources There is more in SNOW-375 for full duplex, but that set represents some of the common client/server requests. If there is a dictionary that has already been negotiated that doesn't assume the client is a single end-point, I would like to know of this so we can work on this together. As you can see from this pic, I do speak of SNOW-375 as a working example: http://twitpic.com/1gl71s Notice the viewer/render/scenegraph is one window and the rest of the UI is each in their own window. These are separate programs, so there is more than one end-point on the client-side. From john.hurliman@intel.com Wed Apr 28 17:08:28 2010 Return-Path: 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 830F83A6959 for ; Wed, 28 Apr 2010 17:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 uHK4Ud9gH5ap for ; Wed, 28 Apr 2010 17:08:27 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 80ECB3A698B for ; Wed, 28 Apr 2010 17:07:59 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 28 Apr 2010 17:05:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,291,1270450800"; d="scan'208";a="562512226" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga002.fm.intel.com with ESMTP; 28 Apr 2010 17:07:13 -0700 Received: from rrsmsx606.amr.corp.intel.com (10.31.1.130) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Apr 2010 18:07:44 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by RRSMSX606.amr.corp.intel.com ([10.31.1.130]) with mapi; Wed, 28 Apr 2010 18:07:43 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Wed, 28 Apr 2010 18:07:40 -0600 Thread-Topic: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion Thread-Index: AcrnJXhRf3HZyuqNT8idEVgyO0ZN/wAB8I6A Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCBA5CF78@rrsmsx506.amr.corp.intel.com> References: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> <4BD8BFA4.8030101@gmail.com> In-Reply-To: <4BD8BFA4.8030101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:08:29 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEem9uYXRhcyBTb2wgW21haWx0 bzpkem9uYXRhc0BnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjgsIDIwMTAg NDowNyBQTQ0KPiBUbzogRGF2aWQgVyBMZXZpbmUNCj4gQ2M6IEh1cmxpbWFuLCBKb2huOyB2d3Jh cEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Z3cmFwXSBTb21lIHRob3VnaHRzIG9uIEpvc2gn cyBMaW5kZW4gTGFiIExlZ2FjeSANCj4gUHJvdG9jb2wgZGlzY3Vzc2lvbg0KPiANCj4gRGF2aWQg VyBMZXZpbmUgd3JvdGU6DQo+PiANCj4+IEFzIEkgc2FpZC4gVmVyeSBtdWNoIHBhcnRseSBiYWtl ZCB0aGlua2luZyBhdCB0aGUgbW9tZW50LCByaXBlIGZvcg0KPj4gZGlzY3Vzc2lvbi4NCj4+IA0K Pj4gLSBEYXZpZA0KPj4gfiBaaGENCj4+IA0KPiANCj4gSSBsb29rZWQgYXJvdW5kIGZvciBhIGRp Y3Rpb25hcnkgb2YgcmVzb3VyY2VzIGZvciBWV1JBUCwgYW5kIGl0IGxvb2tzDQo+IGxpa2UgdGhl cmUgaXNuJ3QgYSBzcGVjaWZpYyBzZXQgZ2l2ZW4gYXMgdGhlIHRpbWUgb2YgdGhlIGUtbWFpbC4g SQ0KPiByZWFkIG92ZXIgdGhlIFZXUkFQIGRvY3MgYW5kIHNlZW4gdGhlIHBhdHRlcm4gdG8gZm9s bG93LiBJIGhlYXJkIHRoZXJlDQo+IGFyZSBzb21lIGltcGxlbWVudGF0aW9ucywgeWV0IHRob3Nl IGltcGxlbWVudGF0aW9ucyBoYXZlbid0IHJlYWxseQ0KPiBleHBvc2VkIGEgZ2l2ZW4gc2V0IGJl eW9uZCB0aGUgc291cmNlcyB0aGF0IGFscmVhZHkgcmV2ZWFsIHRoZSBvbGRlcg0KPiBPR1BYIGlt cGxlbWVudGF0aW9uLg0KPiANCj4gSSBsb29rZWQgZm9yIHRoZSBWV1JBUCByZXNvdXJjZSBkaWN0 aW9uYXJ5IGluIG9yZGVyIHRvIGFsaWduIFNOT1ctMzc1DQo+IHJlc291cmNlcyB3aGVyZSBldmVy IHRoZXkgb3ZlcmxhcC4gU28gZmFyLCBTTk9XLTM3NSBoYXMgdGhlc2U6DQo+IGh0dHBzOi8vd2lr aS5zZWNvbmRsaWZlLmNvbS93aWtpL1VzZXI6RHpvbmF0YXNfU29sL1NOT1ctMzc1X1Jlc291cmNl cw0KPiANCj4gVGhlcmUgaXMgbW9yZSBpbiBTTk9XLTM3NSBmb3IgZnVsbCBkdXBsZXgsIGJ1dCB0 aGF0IHNldCByZXByZXNlbnRzDQo+IHNvbWUgb2YgdGhlIGNvbW1vbiBjbGllbnQvc2VydmVyIHJl cXVlc3RzLg0KPiANCj4gSWYgdGhlcmUgaXMgYSBkaWN0aW9uYXJ5IHRoYXQgaGFzIGFscmVhZHkg YmVlbiBuZWdvdGlhdGVkIHRoYXQgZG9lc24ndA0KPiBhc3N1bWUgdGhlIGNsaWVudCBpcyBhIHNp bmdsZSBlbmQtcG9pbnQsIEkgd291bGQgbGlrZSB0byBrbm93IG9mIHRoaXMNCj4gc28gd2UgY2Fu IHdvcmsgb24gdGhpcyB0b2dldGhlci4NCj4gDQo+IEFzIHlvdSBjYW4gc2VlIGZyb20gdGhpcyBw aWMsIEkgZG8gc3BlYWsgb2YgU05PVy0zNzUgYXMgYSB3b3JraW5nDQo+IGV4YW1wbGU6IGh0dHA6 Ly90d2l0cGljLmNvbS8xZ2w3MXMNCj4gDQo+IE5vdGljZSB0aGUgdmlld2VyL3JlbmRlci9zY2Vu ZWdyYXBoIGlzIG9uZSB3aW5kb3cgYW5kIHRoZSByZXN0IG9mIHRoZQ0KPiBVSSBpcyBlYWNoIGlu IHRoZWlyIG93biB3aW5kb3cuIFRoZXNlIGFyZSBzZXBhcmF0ZSBwcm9ncmFtcywgc28gdGhlcmUN Cj4gaXMgbW9yZSB0aGFuIG9uZSBlbmQtcG9pbnQgb24gdGhlIGNsaWVudC1zaWRlLg0KPiANCj4g DQoNCk5vLCB0aGVyZSBpcyBubyBkaWN0aW9uYXJ5IG9mIHJlc291cmNlcyBkZWZpbmVkIGluIHRo ZSBWV1JBUCBzcGVjIHNvIGZhci4gQWx0aG91Z2ggSSBoYXZlbid0IHNlZW4gYSByb2FkbWFwIGZv ciBWV1JBUCB5ZXQsIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyBpcyBzb21ldGhpbmcgbGlrZSB0 aGlzOg0KDQoxLiBBZ3JlZSBvbiBjb21tb24gbG93IGxldmVsIHByb3RvY29scw0KIGEuIENvbW1v biB0eXBlcw0KIGIuIENvbW1vbiBzZXJpYWxpemF0aW9ucw0KIGMuIENvbW1vbiB0cmFuc3BvcnRz DQoyLiBEZWZpbmUgYSBzeXN0ZW0gZm9yIHJlcXVlc3RpbmcgYW5kIGNvbnN1bWluZyByZXNvdXJj ZXMNCiBhLiBEZWZpbmluZyByZXNvdXJjZSBwcm92aWRlcnMgYW5kIGNvbnN1bWVycw0KIGIuIEF1 dGhvcml6YXRpb24vYXV0aGVudGljYXRpb24NCiBjLiBTZXJ2aWNlIGFuZCBjb250ZW50IG5lZ290 aWF0aW9uDQozLiBEZWZpbmluZyBzZXJ2aWNlIGVuZHBvaW50cw0KIGEuIENhdGVnb3JpemUgZWFj aCBzZXQgb2Ygc2VydmljZSByZXF1aXJlbWVudHMsIGRldGVybWluZSB3aGF0IG5lZWRzIEFQSS1s ZXZlbCBzdGFuZGFyZGl6YXRpb24gYW5kIHdoYXQgaXMgdHJlYXRlZCBhcyBhbiAib3BhcXVlIiBl bmRwb2ludA0KIGIuIFN0YW5kYXJkaXplIG9uZSBvZiB0aGUgc3BlY2lhbCBzZXJ2aWNlIHJlcXVp cmVtZW50cw0KIGMuIFJlcGVhdCBiLiB1bnRpbCBzb21lb25lIGRlY2xhcmVzIHRoZSBjdXJyZW50 IGVmZm9ydCAiZG9uZSINCiBkLiBSZXBlYXQgYi4gYXMgdW5vZmZpY2lhbCBleHRlbnNpb25zIHRo YXQgYWltIHRvIGluZmx1ZW5jZSBWV1JBUDINCg0KDQpXaGVyZSB3ZSBkb27igJl0IHN0YXJ0IHRv IHNlZSBhIG1lYW5pbmdmdWwgbGlzdCBvZiBSRkMtcmVmZXJlbmNlZCBvciBjb21tb25seSB1c2Vk IHNlcnZpY2UgZW5kcG9pbnRzIGFuZCB0aGUgZHJhZnQgcHJvdG9jb2xzIGZvciB0aG9zZSB1bnRp bCBhcm91bmQgM2IsIGFuZCB3ZSdyZSBtb3JlIG9yIGxlc3MgZmluaXNoaW5nIDFjIGFuZCBzdGFy dGluZyBkaXNjdXNzaW9uIG9uIDJhIHJpZ2h0IG5vdyAod2l0aCBzb21lIG9wZW4gZW5kZWQgZGlz Y3Vzc2lvbiBsb29raW5nIGZvcndhcmQgdGhyb3duIGluKS4gVGhpcyBpc24ndCBhbiBvZmZpY2lh bCByb2FkbWFwIG9yIGluc2lkZSBrbm93bGVkZ2UsIGp1c3QgbXkgcGVyc29uYWwgb2JzZXJ2YXRp b24gZnJvbSB0aGUgSS1EcywgSUVURiBnYXRoZXJpbmdzLCB2aXJ0dWFsIG1lZXRpbmdzLCBhbmQg bWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLiBJZiBhbnlvbmUgaGFzIGEgZGVlcGVyIG9yIG1vcmUg Y2xlYXIgaW5zaWdodCBpbnRvIHdoYXQgd2UncmUgZG9pbmcgcGxlYXNlIGNvcnJlY3QgbXkgcm9h ZG1hcC4NCg0KSm9obg0K From ohmeadhbh@gmail.com Wed Apr 28 17:42:34 2010 Return-Path: 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 607E03A6818 for ; Wed, 28 Apr 2010 17:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, 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 odpuuYtfFi-p for ; Wed, 28 Apr 2010 17:42:32 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 6C4953A6816 for ; Wed, 28 Apr 2010 17:42:32 -0700 (PDT) Received: by qyk11 with SMTP id 11so18914674qyk.13 for ; Wed, 28 Apr 2010 17:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=OnrBQr20l5q+8jd8CC24RA0DAjG9qLBr3NJxyhewfWw=; b=ppIIR4tx7R7zXrMRWyasdomHXrYNzneD4Bav6DcqgOFJliQB9T//3xrHDwRNgCNH54 rq8PJnkeq8G59WBs1oRQd/k4dDEMa6Ih2unIuIYksEeTjU4/QpDL0YNSuuRx3TKGDAFS zNiNLqyHbF3TN8Ctkk9YFhCdL7LQ5qyhl3+II= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sDSojHbIqOx/GNb0v3d+YRK8TrQQ2OJN/OHeScTX2cJ5kFlc1JMxs9xVGnkJnz1eYk TD0DqQ4fmVoa9F7BqJ6RaBo8m9LGSW7/P3XOFKQcMlKUnZq8sSFuWsSUQIfDUYHVGXtp MDW9UrRgpBXPDh7sh0F8NaQ439FUVOhKyKd8w= Received: by 10.229.218.147 with SMTP id hq19mr4122280qcb.34.1272501732985; Wed, 28 Apr 2010 17:42:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.142 with HTTP; Wed, 28 Apr 2010 17:37:25 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Wed, 28 Apr 2010 17:37:25 -0700 Message-ID: To: David W Levine Content-Type: multipart/alternative; boundary=00163630f165c54d3d04855565df Cc: vwrap@ietf.org Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:42:34 -0000 --00163630f165c54d3d04855565df Content-Type: text/plain; charset=ISO-8859-1 so i feel your pain, david. but i want to ask, must the protocol specify ALL possible interfaces? isn't it possible for the VWRAP suite of protocols to specify a set of interfaces and resources for a bare minimum and leave the rest to implementers? in other words... i think we can get some radical agreement that authentication and teleportation and so forth are important to all virtual worlds. but we might have some argument that game script and land ownership interfaces are universally important. maybe it's enough in this working group to define the basics and have other features be proprietary extensions? this is one of the features of the OMG process i liked; people could extend "CORBA" all they wanted, but if they wanted their extensions to be part of the spec, they had to spend a few days in hotel bars lobbying other members to not object when it's discussed in the orbos meetings. in other words... would it kill us if we moved forward with what we seem to have agreed to in the chartering process, let people try several different solutions for annotation of objects in the virtual world, write a bunch of competing drafts, then retire to the hotel bar for a few days and come out with an agreement for how we handle different "extensions"? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 27, 2010 at 2:41 PM, David W Levine wrote: > > As always, food for thought, probably partly baked. > > Josh Linden's presentation on the Linden Legacy Protocol > raises the possibility that a substantial number of > operations currently managed by the Linden Labs client be > viewed as "out of scope" for VWRAP and exposed as "there is > a URI/URL which provides access to a service to perform this > task." > > Thus rather than including a set of LLIDL messages which define > how to set parcel permissions, you would associate a "Here is a > URI to invoke to get to a UI about this parcel" > > I would argue this solves roughly 1/3 of the problem. It makes it very > easy for a deployed to provide a customer user interface, and it nicely > reduces the amount of work needed to describe a useful protocol. I also > said 1/3 because I think it misses two things. First, it begs the > question(s) "What cues are needed to let the client know where things > happen" and second, it misses the need to expose the attributes these > interfaces would manage in a programmatic fashion. > > Effectively, the first problem is one of asking "How do we overlay the > scene graph with UI cues." The more I think about it, the more I like > the idea of solving this problem elegantly. In particular, the obvious > design "This portion of the scenegraph or this broad area of virtual > space" has "This URI" to invoke for more information seems pretty > straightforward. How to cue things like "parcel boundaries" and "Has this > property" is a little less obvious, but a good solution would be well > worth having. Notice that this also allows some potentially elegant > integration points. One could expose custom web page UIs as associated > with Vendors, Buildings, portions of the ground, or any part of the > scenegraph. > > The second problem is also one worth solving, tho its more difficult. > I think it falls into two or three parts. The easy bit, is again, the > "cue" issue. In short, how does one find out that there *is* structured > data or an API associated with some portion of virtual space. At one > level, the temptation is to say the web solves this already, and blend > it in with an overall scheme for associating URIs with each bit of > virtual space or virtual item. I'm not sure this is sufficient, but I > think it serves as a nice starting point. > > I think a small worked example would be helpful. This is intended to be > fairly accurate, but clearly not more than a thought experiment. > > Posit a virtual space which wishes to expose an administrative > interface which permits visitors with proper permission to change > several parameters of the physics engine. The current model of things > would require a cap and a custom bit of user interface, or user > interface exposed via some "in world" hook, such as a prim exposing a > web page, or a web page entirely disjoint from the inworld experience. > > Instead, we would provide a way for the region to advertize the > existence of the service to the client. I am, for example, imagining > either a capability exposed by the region, or a public URI/URL exposed by > the client. (Whether the approach is fully web centric, or blended in > with VWRAP style of capability access is clearly something worthy of > discussion) > > The client, on arrival to the region, fetches the URI, using content > negotiation and gets back a "cue" to display to the user that a service > is available. (Content negotiation let web based internationalization > and such simply happens) The cue is presented to the user as the client > sees fit, and if it is invoked, an associated URI launches the > user interface web service, which can be pre-fed with context, based > on the user. > > Now, this is doubly inappropriate for a programmatic approach. We neither > want to make programs screen scrape for content cues, nor do we want to > present them with a nice pretty user interface to manipulate. Thus, > a structured data path would be desirable. More on thinking about how > regions and scenegraph can expose APIs for performing tasks in a future > post > > - David > ~ Zha > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --00163630f165c54d3d04855565df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable so i feel your pain, david.

but i want to ask, must the protocol spe= cify ALL possible interfaces? isn't it possible for the VWRAP suite of = protocols to specify a set of interfaces and resources for a bare minimum a= nd leave the rest to implementers?

in other words... i think we can get some radical agreement that authen= tication and teleportation and so forth are important to all virtual worlds= . but we might have some argument that game script and land ownership inter= faces are universally important.

maybe it's enough in this working group to define the basics and ha= ve other features be proprietary extensions?

this is one of the feat= ures of the OMG process i liked; people could extend "CORBA" all = they wanted, but if they wanted their extensions to be part of the spec, th= ey had to spend a few days in hotel bars lobbying other members to not obje= ct when it's discussed in the orbos meetings.

in other words... would it kill us if we moved forward with what we see= m to have agreed to in the chartering process, let people try several diffe= rent solutions for annotation of objects in the virtual world, write a bunc= h of competing drafts, then retire to the hotel bar for a few days and come= out with an agreement for how we handle different "extensions"?<= br>
-cheers
-meadhbh
--
meadhbh hamrick * it's p= ronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh= @gmail.com


On Tue, Apr 27, 2010 at 2:41 PM, David W= Levine <dwl@us.ibm.= com> wrote:

As always, food for thought, proba= bly partly baked.

Josh Linden's presentation on = the Linden Legacy Protocol
raises the possibility that a subs= tantial number of
operations currently managed by th= e Linden Labs client be
viewed as "out of scope"= for VWRAP and exposed as "there is
a URI/URL which provides access to= a service to perform this
task."

Thus rather than including a set o= f LLIDL messages which define
how to set parcel permissions, you= would associate a "Here is a
URI to invoke to get to a UI about= this parcel"

I would argue this solves roughly = 1/3 of the problem. It makes it very
easy for a deployed to provide a c= ustomer user interface, and it nicely
reduces the amount of work needed = to describe a useful protocol. I also
said 1/3 because I think it misses= two things. First, it begs the
question(s) "What cues are ne= eded to let the client know where things
happen" and second, it misses= the need to expose the attributes these
interfaces would manage in a progr= ammatic fashion.

Effectively, the first problem is = one of asking "How do we overlay the
scene graph with UI cues." Th= e more I think about it, the more I like
the idea of solving this problem e= legantly. In particular, the obvious
design "This portion of the s= cenegraph or this broad area of virtual
space" has "This URI&quo= t; to invoke for more information seems pretty
straightforward. How to cue things= like "parcel boundaries" and "Has this
property" is a little less ob= vious, but a good solution would be well
worth having. Notice that this als= o allows some potentially elegant
integration points. One could expo= se custom web page UIs as associated
with Vendors, Buildings, portions = of the ground, or any part of the
scenegraph.

The second problem is also one wor= th solving, tho its more difficult.
I think it falls into two or three= parts. The easy bit, is again, the
"cue" issue. In short, h= ow does one find out that there *is* structured
data or an API associated with som= e portion of virtual space. At one
level, the temptation is to say th= e web solves this already, and blend
it in with an overall scheme for a= ssociating URIs with each bit of
virtual space or virtual item. I&#= 39;m not sure this is sufficient, but I
think it serves as a nice starting= point.

I think a small worked example wou= ld be helpful. This is intended to be
fairly accurate, but clearly not m= ore than a thought experiment.

Posit a virtual space which wishes= to expose an administrative
interface which permits visitors w= ith proper permission to change
several parameters of the physics = engine. The current model of things
would require a cap and a custom b= it of user interface, or user
interface exposed via some "i= n world" hook, such as a prim exposing a
web page, or a web page entirely d= isjoint from the inworld experience.

Instead, we would provide a way fo= r the region to advertize the
existence of the service to the cl= ient. I am, for example, imagining
either a capability exposed by the= region, or a public URI/URL exposed by
the client. (Whether the approach = is fully web centric, or blended in
with VWRAP style of capability acc= ess is clearly something worthy of
discussion) =A0

The client, on arrival to the regi= on, fetches the URI, using content
negotiation and gets back a "= cue" to display to the user that a service
is available. (Content negotiation= let web based internationalization
and such simply happens) The cue i= s presented to the user as the client
sees fit, and if it is invoked, an= associated URI launches the
user interface web service, which = can be pre-fed with context, based
on the user.

Now, this is doubly inappropriate = for a programmatic approach. We neither
want to make programs screen scrap= e for content cues, nor do we want to
present them with a nice pretty us= er interface to manipulate. Thus,
a structured data path would be de= sirable. More on thinking about how
regions and scenegraph can expose = APIs for performing tasks in a future post

- David
~ Zha

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--00163630f165c54d3d04855565df-- From john.hurliman@intel.com Wed Apr 28 17:59:56 2010 Return-Path: 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 BA9703A6A4E for ; Wed, 28 Apr 2010 17:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 7gqkjXSuOkVN for ; Wed, 28 Apr 2010 17:59:55 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 2DFD23A6816 for ; Wed, 28 Apr 2010 17:59:55 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Apr 2010 17:57:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,291,1270450800"; d="scan'208";a="617386570" Received: from adenosine.sc.intel.com (HELO [143.183.81.109]) ([143.183.81.109]) by orsmga001.jf.intel.com with ESMTP; 28 Apr 2010 17:59:21 -0700 Message-ID: <4BD8D9F3.9000709@intel.com> Date: Wed, 28 Apr 2010 17:59:31 -0700 From: John Hurliman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:59:56 -0000 +1 to moving forward with a bare minimum set of requirements. The trap I want to avoid is getting rough consensus that there are a ten different areas where we need to standardize communication, but when it comes time to actually doing the standards work it turns out only five of those areas are relevant to the active participants. The other five areas receive a fair dose of idle speculation, but otherwise go nowhere and stall the overall process. If anyone identifies a specific resource (service endpoint, set of endpoints, suite of bi-directional events, whatever) that they want to see standardized, I would prefer to see it drafted / prototyped / alpha tested before arguing that it should be officially sanctioned by VWRAP. John On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote: > so i feel your pain, david. > > but i want to ask, must the protocol specify ALL possible interfaces? > isn't it possible for the VWRAP suite of protocols to specify a set of > interfaces and resources for a bare minimum and leave the rest to > implementers? > > in other words... i think we can get some radical agreement that > authentication and teleportation and so forth are important to all > virtual worlds. but we might have some argument that game script and > land ownership interfaces are universally important. > > maybe it's enough in this working group to define the basics and have > other features be proprietary extensions? > > this is one of the features of the OMG process i liked; people could > extend "CORBA" all they wanted, but if they wanted their extensions to > be part of the spec, they had to spend a few days in hotel bars lobbying > other members to not object when it's discussed in the orbos meetings. > > in other words... would it kill us if we moved forward with what we seem > to have agreed to in the chartering process, let people try several > different solutions for annotation of objects in the virtual world, > write a bunch of competing drafts, then retire to the hotel bar for a > few days and come out with an agreement for how we handle different > "extensions"? > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Apr 27, 2010 at 2:41 PM, David W Levine > wrote: > > > As always, food for thought, probably partly baked. > > Josh Linden's presentation on the Linden Legacy Protocol > raises the possibility that a substantial number of > operations currently managed by the Linden Labs client be > viewed as "out of scope" for VWRAP and exposed as "there is > a URI/URL which provides access to a service to perform this > task." > > Thus rather than including a set of LLIDL messages which define > how to set parcel permissions, you would associate a "Here is a > URI to invoke to get to a UI about this parcel" > > I would argue this solves roughly 1/3 of the problem. It makes it very > easy for a deployed to provide a customer user interface, and it nicely > reduces the amount of work needed to describe a useful protocol. I also > said 1/3 because I think it misses two things. First, it begs the > question(s) "What cues are needed to let the client know where things > happen" and second, it misses the need to expose the attributes these > interfaces would manage in a programmatic fashion. > > Effectively, the first problem is one of asking "How do we overlay the > scene graph with UI cues." The more I think about it, the more I like > the idea of solving this problem elegantly. In particular, the obvious > design "This portion of the scenegraph or this broad area of virtual > space" has "This URI" to invoke for more information seems pretty > straightforward. How to cue things like "parcel boundaries" and "Has > this > property" is a little less obvious, but a good solution would be well > worth having. Notice that this also allows some potentially elegant > integration points. One could expose custom web page UIs as associated > with Vendors, Buildings, portions of the ground, or any part of the > scenegraph. > > The second problem is also one worth solving, tho its more difficult. > I think it falls into two or three parts. The easy bit, is again, the > "cue" issue. In short, how does one find out that there *is* structured > data or an API associated with some portion of virtual space. At one > level, the temptation is to say the web solves this already, and blend > it in with an overall scheme for associating URIs with each bit of > virtual space or virtual item. I'm not sure this is sufficient, but I > think it serves as a nice starting point. > > I think a small worked example would be helpful. This is intended to be > fairly accurate, but clearly not more than a thought experiment. > > Posit a virtual space which wishes to expose an administrative > interface which permits visitors with proper permission to change > several parameters of the physics engine. The current model of things > would require a cap and a custom bit of user interface, or user > interface exposed via some "in world" hook, such as a prim exposing a > web page, or a web page entirely disjoint from the inworld experience. > > Instead, we would provide a way for the region to advertize the > existence of the service to the client. I am, for example, imagining > either a capability exposed by the region, or a public URI/URL > exposed by > the client. (Whether the approach is fully web centric, or blended in > with VWRAP style of capability access is clearly something worthy of > discussion) > > The client, on arrival to the region, fetches the URI, using content > negotiation and gets back a "cue" to display to the user that a service > is available. (Content negotiation let web based internationalization > and such simply happens) The cue is presented to the user as the client > sees fit, and if it is invoked, an associated URI launches the > user interface web service, which can be pre-fed with context, based > on the user. > > Now, this is doubly inappropriate for a programmatic approach. We > neither > want to make programs screen scrape for content cues, nor do we want to > present them with a nice pretty user interface to manipulate. Thus, > a structured data path would be desirable. More on thinking about how > regions and scenegraph can expose APIs for performing tasks in a > future post > > - David > ~ Zha > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Wed Apr 28 22:05:01 2010 Return-Path: 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 00EDF3A6ACE for ; Wed, 28 Apr 2010 22:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_50=0.001, 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 0K5zEfyg5N0T for ; Wed, 28 Apr 2010 22:04:58 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 201603A6885 for ; Wed, 28 Apr 2010 22:04:57 -0700 (PDT) Received: by qyk11 with SMTP id 11so19191344qyk.13 for ; Wed, 28 Apr 2010 22:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=ys1oR7xFR1mNK78v5qg2edWcZTmqGupg5GbC0xWrmdY=; b=EvcNEc21i/WzBB/mJFt34NSDxA0Pk6/TodlJXNf91msr3A57/7LJL8q26fSRYFQMLz K63r95O4xk2yanstneko9h0ysFLWdnaxjXOR/kO8kWji/sGP/NXRuzjiYXMTJOV1fREP 7iMQavDpODKZpJfLpRFpGDYmgr+xMaU9Gh2Fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=x8/ptqzEf+vUNjovRVEgGb9iJQmfYCNSrsf6u+rAsziDEOml6u+yq5nkrwRjbwhVkh MV6Xgb5mkMpCVdandPnwxeNwSS2TUjuVB6TUD+RsMIWaxkOJofjd+dujtWBTukERBIRL Y1ltzrrH81vTq+Wp9oO9TgxjlhWjR8g0TzIkU= Received: by 10.224.96.166 with SMTP id h38mr2319998qan.199.1272517481209; Wed, 28 Apr 2010 22:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.142 with HTTP; Wed, 28 Apr 2010 22:04:21 -0700 (PDT) In-Reply-To: <4BD8D9F3.9000709@intel.com> References: <4BD8D9F3.9000709@intel.com> From: Meadhbh Hamrick Date: Wed, 28 Apr 2010 22:04:21 -0700 Message-ID: To: John Hurliman Content-Type: multipart/alternative; boundary=00c09f986ac3701f6e0485591051 Cc: vwrap@ietf.org Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 05:05:01 -0000 --00c09f986ac3701f6e0485591051 Content-Type: text/plain; charset=ISO-8859-1 this is part of the reason we wanted to break stuff up in to different documents. say all the docs we propose become RFCs, deployers could choose to implement some, but not all of the RFCs. eventually if we want VWRAP to advance to the "real" standard stage, you have to demonstrate at least two genetically distinct implementations. so as we move forward, if it turns out that we lose interest in half the specs, they can wither and die without affecting the others. or at least that was the idea. and i think barry and josh can comment on this a little more authoritatively, but my understanding is that if, as a group, we decide to add a new document to the charter, it's not _that_ difficult to do. removing documents is a little harder, but not completely impossible. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Wed, Apr 28, 2010 at 5:59 PM, John Hurliman wrote: > +1 to moving forward with a bare minimum set of requirements. The trap I > want to avoid is getting rough consensus that there are a ten different > areas where we need to standardize communication, but when it comes time to > actually doing the standards work it turns out only five of those areas are > relevant to the active participants. The other five areas receive a fair > dose of idle speculation, but otherwise go nowhere and stall the overall > process. > > If anyone identifies a specific resource (service endpoint, set of > endpoints, suite of bi-directional events, whatever) that they want to see > standardized, I would prefer to see it drafted / prototyped / alpha tested > before arguing that it should be officially sanctioned by VWRAP. > > John > > > On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote: > >> so i feel your pain, david. >> >> but i want to ask, must the protocol specify ALL possible interfaces? >> isn't it possible for the VWRAP suite of protocols to specify a set of >> interfaces and resources for a bare minimum and leave the rest to >> implementers? >> >> in other words... i think we can get some radical agreement that >> authentication and teleportation and so forth are important to all >> virtual worlds. but we might have some argument that game script and >> land ownership interfaces are universally important. >> >> maybe it's enough in this working group to define the basics and have >> other features be proprietary extensions? >> >> this is one of the features of the OMG process i liked; people could >> extend "CORBA" all they wanted, but if they wanted their extensions to >> be part of the spec, they had to spend a few days in hotel bars lobbying >> other members to not object when it's discussed in the orbos meetings. >> >> in other words... would it kill us if we moved forward with what we seem >> to have agreed to in the chartering process, let people try several >> different solutions for annotation of objects in the virtual world, >> write a bunch of competing drafts, then retire to the hotel bar for a >> few days and come out with an agreement for how we handle different >> "extensions"? >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> >> On Tue, Apr 27, 2010 at 2:41 PM, David W Levine > > wrote: >> >> >> As always, food for thought, probably partly baked. >> >> Josh Linden's presentation on the Linden Legacy Protocol >> raises the possibility that a substantial number of >> operations currently managed by the Linden Labs client be >> viewed as "out of scope" for VWRAP and exposed as "there is >> a URI/URL which provides access to a service to perform this >> task." >> >> Thus rather than including a set of LLIDL messages which define >> how to set parcel permissions, you would associate a "Here is a >> URI to invoke to get to a UI about this parcel" >> >> I would argue this solves roughly 1/3 of the problem. It makes it very >> easy for a deployed to provide a customer user interface, and it nicely >> reduces the amount of work needed to describe a useful protocol. I also >> said 1/3 because I think it misses two things. First, it begs the >> question(s) "What cues are needed to let the client know where things >> happen" and second, it misses the need to expose the attributes these >> interfaces would manage in a programmatic fashion. >> >> Effectively, the first problem is one of asking "How do we overlay the >> scene graph with UI cues." The more I think about it, the more I like >> the idea of solving this problem elegantly. In particular, the obvious >> design "This portion of the scenegraph or this broad area of virtual >> space" has "This URI" to invoke for more information seems pretty >> straightforward. How to cue things like "parcel boundaries" and "Has >> this >> property" is a little less obvious, but a good solution would be well >> worth having. Notice that this also allows some potentially elegant >> integration points. One could expose custom web page UIs as associated >> with Vendors, Buildings, portions of the ground, or any part of the >> scenegraph. >> >> The second problem is also one worth solving, tho its more difficult. >> I think it falls into two or three parts. The easy bit, is again, the >> "cue" issue. In short, how does one find out that there *is* structured >> data or an API associated with some portion of virtual space. At one >> level, the temptation is to say the web solves this already, and blend >> it in with an overall scheme for associating URIs with each bit of >> virtual space or virtual item. I'm not sure this is sufficient, but I >> think it serves as a nice starting point. >> >> I think a small worked example would be helpful. This is intended to be >> fairly accurate, but clearly not more than a thought experiment. >> >> Posit a virtual space which wishes to expose an administrative >> interface which permits visitors with proper permission to change >> several parameters of the physics engine. The current model of things >> would require a cap and a custom bit of user interface, or user >> interface exposed via some "in world" hook, such as a prim exposing a >> web page, or a web page entirely disjoint from the inworld experience. >> >> Instead, we would provide a way for the region to advertize the >> existence of the service to the client. I am, for example, imagining >> either a capability exposed by the region, or a public URI/URL >> exposed by >> the client. (Whether the approach is fully web centric, or blended in >> with VWRAP style of capability access is clearly something worthy of >> discussion) >> >> The client, on arrival to the region, fetches the URI, using content >> negotiation and gets back a "cue" to display to the user that a service >> is available. (Content negotiation let web based internationalization >> and such simply happens) The cue is presented to the user as the client >> sees fit, and if it is invoked, an associated URI launches the >> user interface web service, which can be pre-fed with context, based >> on the user. >> >> Now, this is doubly inappropriate for a programmatic approach. We >> neither >> want to make programs screen scrape for content cues, nor do we want to >> present them with a nice pretty user interface to manipulate. Thus, >> a structured data path would be desirable. More on thinking about how >> regions and scenegraph can expose APIs for performing tasks in a >> future post >> >> - David >> ~ Zha >> >> _______________________________________________ >> 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 > --00c09f986ac3701f6e0485591051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable this is part of the reason we wanted to break stuff up in to different docu= ments. say all the docs we propose become RFCs, deployers could choose to i= mplement some, but not all of the RFCs. eventually if we want VWRAP to adva= nce to the "real" standard stage, you have to demonstrate at leas= t two genetically distinct implementations.

so as we move forward, if it turns out that we lose interest= in half the specs, they can wither and die without affecting the others. o= r at least that was the idea.

and i think barry an= d josh can comment on this a little more authoritatively, but my understand= ing is that if, as a group, we decide to add a new document to the charter,= it's not _that_ difficult to do. removing documents is a little harder= , but not completely impossible.

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


On Wed, Apr 28, 2010 at 5:59 PM, John Hu= rliman <joh= n.hurliman@intel.com> wrote:
+1 to moving forward with a bare minimum set of requirements. The trap I wa= nt to avoid is getting rough consensus that there are a ten different areas= where we need to standardize communication, but when it comes time to actu= ally doing the standards work it turns out only five of those areas are rel= evant to the active participants. The other five areas receive a fair dose = of idle speculation, but otherwise go nowhere and stall the overall process= .

If anyone identifies a specific resource (service endpoint, set of endpoint= s, suite of bi-directional events, whatever) that they want to see standard= ized, I would prefer to see it drafted / prototyped / alpha tested before a= rguing that it should be officially sanctioned by VWRAP.

John


On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:
so i feel your pain, david.

but i want to ask, must the protocol specify ALL possible interfaces?
isn't it possible for the VWRAP suite of protocols to specify a set of<= br> interfaces and resources for a bare minimum and leave the rest to
implementers?

in other words... i think we can get some radical agreement that
authentication and teleportation and so forth are important to all
virtual worlds. but we might have some argument that game script and
land ownership interfaces are universally important.

maybe it's enough in this working group to define the basics and have other features be proprietary extensions?

this is one of the features of the OMG process i liked; people could
extend "CORBA" all they wanted, but if they wanted their extensio= ns to
be part of the spec, they had to spend a few days in hotel bars lobbying other members to not object when it's discussed in the orbos meetings.<= br>
in other words... would it kill us if we moved forward with what we seem to have agreed to in the chartering process, let people try several
different solutions for annotation of objects in the virtual world,
write a bunch of competing drafts, then retire to the hotel bar for a
few days and come out with an agreement for how we handle different
"extensions"?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMe= adhbh@gmail.com
<mailto:OhMeadh= bh@gmail.com>



On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <dwl@us.ibm.com
<mailto:dwl@us.ibm.c= om>> wrote:


=A0 =A0As always, food for thought, probably partly baked.

=A0 =A0Josh Linden's presentation on the Linden Legacy Protocol
=A0 =A0raises the possibility that a substantial number of
=A0 =A0operations currently managed by the Linden Labs client be
=A0 =A0viewed as "out of scope" for VWRAP and exposed as "t= here is
=A0 =A0a URI/URL which provides access to a service to perform this
=A0 =A0task."

=A0 =A0Thus rather than including a set of LLIDL messages which define
=A0 =A0how to set parcel permissions, you would associate a "Here is = a
=A0 =A0URI to invoke to get to a UI about this parcel"

=A0 =A0I would argue this solves roughly 1/3 of the problem. It makes it v= ery
=A0 =A0easy for a deployed to provide a customer user interface, and it ni= cely
=A0 =A0reduces the amount of work needed to describe a useful protocol. I = also
=A0 =A0said 1/3 because I think it misses two things. First, it begs the =A0 =A0question(s) "What cues are needed to let the client know where= things
=A0 =A0happen" and second, it misses the need to expose the attribute= s these
=A0 =A0interfaces would manage in a programmatic fashion.

=A0 =A0Effectively, the first problem is one of asking "How do we ove= rlay the
=A0 =A0scene graph with UI cues." The more I think about it, the more= I like
=A0 =A0the idea of solving this problem elegantly. In particular, the obvi= ous
=A0 =A0design "This portion of the scenegraph or this broad area of v= irtual
=A0 =A0space" has "This URI" to invoke for more information= seems pretty
=A0 =A0straightforward. How to cue things like "parcel boundaries&quo= t; and "Has
=A0 =A0this
=A0 =A0property" is a little less obvious, but a good solution would = be well
=A0 =A0worth having. Notice that this also allows some potentially elegant=
=A0 =A0integration points. One could expose custom web page UIs as associa= ted
=A0 =A0with Vendors, Buildings, portions of the ground, or any part of the=
=A0 =A0scenegraph.

=A0 =A0The second problem is also one worth solving, tho its more difficul= t.
=A0 =A0I think it falls into two or three parts. The easy bit, is again, t= he
=A0 =A0"cue" issue. In short, how does one find out that there *= is* structured
=A0 =A0data or an API associated with some portion of virtual space. At on= e
=A0 =A0level, the temptation is to say the web solves this already, and bl= end
=A0 =A0it in with an overall scheme for associating URIs with each bit of<= br> =A0 =A0virtual space or virtual item. I'm not sure this is sufficient,= but I
=A0 =A0think it serves as a nice starting point.

=A0 =A0I think a small worked example would be helpful. This is intended t= o be
=A0 =A0fairly accurate, but clearly not more than a thought experiment.
=A0 =A0Posit a virtual space which wishes to expose an administrative
=A0 =A0interface which permits visitors with proper permission to change =A0 =A0several parameters of the physics engine. The current model of thin= gs
=A0 =A0would require a cap and a custom bit of user interface, or user
=A0 =A0interface exposed via some "in world" hook, such as a pri= m exposing a
=A0 =A0web page, or a web page entirely disjoint from the inworld experien= ce.

=A0 =A0Instead, we would provide a way for the region to advertize the
=A0 =A0existence of the service to the client. I am, for example, imaginin= g
=A0 =A0either a capability exposed by the region, or a public URI/URL
=A0 =A0exposed by
=A0 =A0the client. (Whether the approach is fully web centric, or blended = in
=A0 =A0with VWRAP style of capability access is clearly something worthy o= f
=A0 =A0discussion)

=A0 =A0The client, on arrival to the region, fetches the URI, using conten= t
=A0 =A0negotiation and gets back a "cue" to display to the user = that a service
=A0 =A0is available. (Content negotiation let web based internationalizati= on
=A0 =A0and such simply happens) The cue is presented to the user as the cl= ient
=A0 =A0sees fit, and if it is invoked, an associated URI launches the
=A0 =A0user interface web service, which can be pre-fed with context, base= d
=A0 =A0on the user.

=A0 =A0Now, this is doubly inappropriate for a programmatic approach. We =A0 =A0neither
=A0 =A0want to make programs screen scrape for content cues, nor do we wan= t to
=A0 =A0present them with a nice pretty user interface to manipulate. Thus,=
=A0 =A0a structured data path would be desirable. More on thinking about h= ow
=A0 =A0regions and scenegraph can expose APIs for performing tasks in a =A0 =A0future post

=A0 =A0- David
=A0 =A0~ Zha

=A0 =A0_______________________________________________
=A0 =A0vwrap mailing list
=A0 =A0vwrap@ietf.org<= /a> <mailto:vwrap@ie= tf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00c09f986ac3701f6e0485591051-- From morgaine.dinova@googlemail.com Thu Apr 29 06:12:49 2010 Return-Path: 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 B7A533A68F3 for ; Thu, 29 Apr 2010 06:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 sVFbKpl-U2aT for ; Thu, 29 Apr 2010 06:12:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C5A6628C25E for ; Thu, 29 Apr 2010 06:08:39 -0700 (PDT) Received: by wwi17 with SMTP id 17so1853001wwi.31 for ; Thu, 29 Apr 2010 06:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=qb1/gmQKBB8wQRfOw6BfLmKQ5XeUzA+EzP+64/X980Y=; b=x7YLUtq+fhKfcWAVEPiVUF2ZGcV8T7sK+vfgMGKxCvmeTKxuFZjMsozCRHf+26kJj+ s0DrmGishxWrG/O/rT3vIfl2p4NEjocyocZxN0v02KmFwsJoKmvysvvLYCopRC4/+lgm ZqsCl5/ofiirpIbPKcHBmBwuP6bpFfhQB6eTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=huCAfA4D1i9yfIVAqul05nnngaR1Dn1zfjbLlBPpQ6+IdIwJ3xUCiODF/sirpRIwmI YlkUMFIe0TiC0hteOjq2jn+qMd290RZ1hQjrh+Mv4h2HrHC3VIyw2HYg+k6iAeE+lDeK ijJ8So2HhSLQ/t49VEC/8+dCr5uc2tELWzpXk= MIME-Version: 1.0 Received: by 10.216.85.135 with SMTP id u7mr9246301wee.51.1272546496049; Thu, 29 Apr 2010 06:08:16 -0700 (PDT) Received: by 10.216.25.6 with HTTP; Thu, 29 Apr 2010 06:08:15 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCBA5CF78@rrsmsx506.amr.corp.intel.com> References: <5FD507B0-6D81-4945-9D8A-DE3FF81C7507@intel.com> <4BD8BFA4.8030101@gmail.com> <62BFE5680C037E4DA0B0A08946C0933DCBA5CF78@rrsmsx506.amr.corp.intel.com> Date: Thu, 29 Apr 2010 14:08:15 +0100 Message-ID: From: Morgaine To: "vwrap@ietf.org" Content-Type: multipart/alternative; boundary=0016e6d77c45dbe96004855fd188 Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 13:12:49 -0000 --0016e6d77c45dbe96004855fd188 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm glad to see Dzonatas bring this topic to the fore. When designing a software system or a protocol in the REST architectural style, the task of problem analysis is first and foremost concerned with splitting the problem space into REST resources or nouns. This is as central to REST as analyzing a problem into classes and objects is in Object-Oriented design. Unless you know what your nouns are, you don't actually have anything concrete to talk about (in the REST sense). I've been trying to get a list of REST nouns out of OGP designers since the beginning of the AWG effort, and the response has always been that "it's coming shortly". It is a puzzl= e to me why it never materialized. If in VWRAP we are choosing to stick with REST, then I suggest that we had better populate our noun-space rather quickly, because a REST-based protoco= l is best defined as the messaging that operates a state machine over the states of its REST nouns. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Apr 29, 2010 at 1:07 AM, Hurliman, John wr= ote: > > -----Original Message----- > > From: Dzonatas Sol [mailto:dzonatas@gmail.com] > > Sent: Wednesday, April 28, 2010 4:07 PM > > To: David W Levine > > Cc: Hurliman, John; vwrap@ietf.org > > Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy > > Protocol discussion > > > > David W Levine wrote: > >> > >> As I said. Very much partly baked thinking at the moment, ripe for > >> discussion. > >> > >> - David > >> ~ Zha > >> > > > > I looked around for a dictionary of resources for VWRAP, and it looks > > like there isn't a specific set given as the time of the e-mail. I > > read over the VWRAP docs and seen the pattern to follow. I heard there > > are some implementations, yet those implementations haven't really > > exposed a given set beyond the sources that already reveal the older > > OGPX implementation. > > > > I looked for the VWRAP resource dictionary in order to align SNOW-375 > > resources where ever they overlap. So far, SNOW-375 has these: > > https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources > > > > There is more in SNOW-375 for full duplex, but that set represents > > some of the common client/server requests. > > > > If there is a dictionary that has already been negotiated that doesn't > > assume the client is a single end-point, I would like to know of this > > so we can work on this together. > > > > As you can see from this pic, I do speak of SNOW-375 as a working > > example: http://twitpic.com/1gl71s > > > > Notice the viewer/render/scenegraph is one window and the rest of the > > UI is each in their own window. These are separate programs, so there > > is more than one end-point on the client-side. > > > > > > No, there is no dictionary of resources defined in the VWRAP spec so far. > Although I haven't seen a roadmap for VWRAP yet, my current understanding= is > something like this: > > 1. Agree on common low level protocols > a. Common types > b. Common serializations > c. Common transports > 2. Define a system for requesting and consuming resources > a. Defining resource providers and consumers > b. Authorization/authentication > c. Service and content negotiation > 3. Defining service endpoints > a. Categorize each set of service requirements, determine what needs > API-level standardization and what is treated as an "opaque" endpoint > b. Standardize one of the special service requirements > c. Repeat b. until someone declares the current effort "done" > d. Repeat b. as unofficial extensions that aim to influence VWRAP2 > > > Where we don=92t start to see a meaningful list of RFC-referenced or comm= only > used service endpoints and the draft protocols for those until around 3b, > and we're more or less finishing 1c and starting discussion on 2a right n= ow > (with some open ended discussion looking forward thrown in). This isn't a= n > official roadmap or inside knowledge, just my personal observation from t= he > I-Ds, IETF gatherings, virtual meetings, and mailing list discussions. If > anyone has a deeper or more clear insight into what we're doing please > correct my roadmap. > > John > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016e6d77c45dbe96004855fd188 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm glad to see Dzonatas bring this topic to the fore.

When desi= gning a software system or a protocol in the REST architectural style, the = task of problem analysis is first and foremost concerned with splitting the= problem space into REST resources or nouns.=A0 This is as central to REST = as analyzing a problem into classes and objects is in Object-Oriented desig= n.

Unless you know what your nouns are, you don't actually have anythi= ng concrete to talk about (in the REST sense).=A0 I've been trying to g= et a list of REST nouns out of OGP designers since the beginning of the AWG= effort, and the response has always been that "it's coming shortl= y".=A0 It is a puzzle to me why it never materialized.

If in VWRAP we are choosing to stick with REST, then I suggest that we = had better populate our noun-space rather quickly, because a REST-based pro= tocol is best defined as the messaging that operates a state machine over t= he states of its REST nouns.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Thu, Apr 29, 2010 at 1:07 AM, Hurliman, = John <john.= hurliman@intel.com> wrote:
> -----Original Message-----
> From: Dzonatas Sol [mailto:dzona= tas@gmail.com]
> Sent: Wednesday, April 28, 2010 4:07 PM
> To: David W Levine
> Cc: Hurliman, John; vwrap@ietf.org
> Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy
> Protocol discussion
>
> David W Levine wrote:
>>
>> As I said. Very much partly baked thinking at the moment, ripe for=
>> discussion.
>>
>> - David
>> ~ Zha
>>
>
> I looked around for a dictionary of resources for VWRAP, and it looks<= br> > like there isn't a specific set given as the time of the e-mail. I=
> read over the VWRAP docs and seen the pattern to follow. I heard there=
> are some implementations, yet those implementations haven't really=
> exposed a given set beyond the sources that already reveal the older > OGPX implementation.
>
> I looked for the VWRAP resource dictionary in order to align SNOW-375<= br> > resources where ever they overlap. So far, SNOW-375 has these:
> https://wiki.secondlife.com/wiki/User:Dzonata= s_Sol/SNOW-375_Resources
>
> There is more in SNOW-375 for full duplex, but that set represents
> some of the common client/server requests.
>
> If there is a dictionary that has already been negotiated that doesn&#= 39;t
> assume the client is a single end-point, I would like to know of this<= br> > so we can work on this together.
>
> As you can see from this pic, I do speak of SNOW-375 as a working
> example: http:= //twitpic.com/1gl71s
>
> Notice the viewer/render/scenegraph is one window and the rest of the<= br> > UI is each in their own window. These are separate programs, so there<= br> > is more than one end-point on the client-side.
>
>

No, there is no dictionary of resources defined in the VWRAP sp= ec so far. Although I haven't seen a roadmap for VWRAP yet, my current = understanding is something like this:

1. Agree on common low level protocols
=A0a. Common types
=A0b. Common serializations
=A0c. Common transports
2. Define a system for requesting and consuming resources
=A0a. Defining resource providers and consumers
=A0b. Authorization/authentication
=A0c. Service and content negotiation
3. Defining service endpoints
=A0a. Categorize each set of service requirements, determine what needs API= -level standardization and what is treated as an "opaque" endpoin= t
=A0b. Standardize one of the special service requirements
=A0c. Repeat b. until someone declares the current effort "done"<= br> =A0d. Repeat b. as unofficial extensions that aim to influence VWRAP2


Where we don=92t start to see a meaningful list of RFC-referenced or common= ly used service endpoints and the draft protocols for those until around 3b= , and we're more or less finishing 1c and starting discussion on 2a rig= ht now (with some open ended discussion looking forward thrown in). This is= n't an official roadmap or inside knowledge, just my personal observati= on from the I-Ds, IETF gatherings, virtual meetings, and mailing list discu= ssions. If anyone has a deeper or more clear insight into what we're do= ing please correct my roadmap.

John
__________________________________= _____________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e6d77c45dbe96004855fd188-- From dwl@us.ibm.com Thu Apr 29 07:48:27 2010 Return-Path: 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 C234C3A69B9 for ; Thu, 29 Apr 2010 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] 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 ts0-JjLW5w+F for ; Thu, 29 Apr 2010 07:48:25 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 452293A69B3 for ; Thu, 29 Apr 2010 07:48:25 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3TEZxEa020002 for ; Thu, 29 Apr 2010 10:35:59 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3TEmAXT1228988 for ; Thu, 29 Apr 2010 10:48:10 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3TEm9rB027752 for ; Thu, 29 Apr 2010 10:48:10 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3TEm9Sh027730; Thu, 29 Apr 2010 10:48:09 -0400 In-Reply-To: References: To: Meadhbh Hamrick MIME-Version: 1.0 X-KeepSent: 1CE1830C:14529DF1-85257714:004FCB9D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 29 Apr 2010 10:48:03 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 04/29/2010 10:48:09, Serialize complete at 04/29/2010 10:48:09 Content-Type: multipart/alternative; boundary="=_alternative 00514E9E85257714_=" Cc: vwrap@ietf.org Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:48:27 -0000 This is a multipart message in MIME format. --=_alternative 00514E9E85257714_= Content-Type: text/plain; charset="US-ASCII" Its interesting. I took Josh's presentation as part of an attempt to look at how we avoid having to specify a ton of stuff when we get to the next round of effort, and very much an attempt to stir some thought. In particular, Josh's proposed approach is very much an effort to keep VWRAP *out* of the business of specifying stuff it doesn't need to specify. That said at the "Lets talk about how we might approach problems" level, it raised some interesting questions. Questions I think need some love at the "Does this provide a framework which would let us totally avoid a TON of work in the mainline of the workgroup" level. The WHOLE point of Josh's proposal and my comments on it is to see if we can define a simple model so that implementers of virtual space services (regions) can expose proprietary extensions in a way which cues the consumer, and gets the protocol out of the way. I think its not only enough for the group to define the basics, but the only way forward. But, that actually means looking at patterns like "how do I associate my private service with part of the scene I am serving" The example I gave was explicitly described as "so how might this work" not "We should specify this." I think we can start to work out how regions ought to work in parallel with updating the base getting teleport published and merging in the content we've all agreed needs merging. The presentation Josh produced on the legacy protocols is at a high level of lets start thinking about this, as was my response. The ideal out come of that would be a "Yes, this could work"or "Oh, no, it misses these three things, lets see how that would work" as input into describing a very concrete, small set of building blocks which would allow regions to standup proprietary services with web style user interfaces hosted by those services (Nicely requiring zero work from VWRAP) and possibly, also showing how to permit API style services to follow the same path. - David ~ Zha Meadhbh Hamrick wrote on 04/28/2010 08:37:25 PM: > [image removed] > > Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion > > Meadhbh Hamrick > > to: > > David W Levine > > 04/28/2010 08:42 PM > > Cc: > > vwrap > > so i feel your pain, david. > > but i want to ask, must the protocol specify ALL possible > interfaces? isn't it possible for the VWRAP suite of protocols to > specify a set of interfaces and resources for a bare minimum and > leave the rest to implementers? > > in other words... i think we can get some radical agreement that > authentication and teleportation and so forth are important to all > virtual worlds. but we might have some argument that game script and > land ownership interfaces are universally important. > > maybe it's enough in this working group to define the basics and > have other features be proprietary extensions? > > this is one of the features of the OMG process i liked; people could > extend "CORBA" all they wanted, but if they wanted their extensions > to be part of the spec, they had to spend a few days in hotel bars > lobbying other members to not object when it's discussed in the > orbos meetings. > > in other words... would it kill us if we moved forward with what we > seem to have agreed to in the chartering process, let people try > several different solutions for annotation of objects in the virtual > world, write a bunch of competing drafts, then retire to the hotel > bar for a few days and come out with an agreement for how we handle > different "extensions"? > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > On Tue, Apr 27, 2010 at 2:41 PM, David W Levine wrote: > > As always, food for thought, probably partly baked. > > Josh Linden's presentation on the Linden Legacy Protocol > raises the possibility that a substantial number of > operations currently managed by the Linden Labs client be > viewed as "out of scope" for VWRAP and exposed as "there is > a URI/URL which provides access to a service to perform this > task." > > Thus rather than including a set of LLIDL messages which define > how to set parcel permissions, you would associate a "Here is a > URI to invoke to get to a UI about this parcel" > > I would argue this solves roughly 1/3 of the problem. It makes it very > easy for a deployed to provide a customer user interface, and it nicely > reduces the amount of work needed to describe a useful protocol. I also > said 1/3 because I think it misses two things. First, it begs the > question(s) "What cues are needed to let the client know where things > happen" and second, it misses the need to expose the attributes these > interfaces would manage in a programmatic fashion. > > Effectively, the first problem is one of asking "How do we overlay the > scene graph with UI cues." The more I think about it, the more I like > the idea of solving this problem elegantly. In particular, the obvious > design "This portion of the scenegraph or this broad area of virtual > space" has "This URI" to invoke for more information seems pretty > straightforward. How to cue things like "parcel boundaries" and "Has this > property" is a little less obvious, but a good solution would be well > worth having. Notice that this also allows some potentially elegant > integration points. One could expose custom web page UIs as associated > with Vendors, Buildings, portions of the ground, or any part of the > scenegraph. > > The second problem is also one worth solving, tho its more difficult. > I think it falls into two or three parts. The easy bit, is again, the > "cue" issue. In short, how does one find out that there *is* structured > data or an API associated with some portion of virtual space. At one > level, the temptation is to say the web solves this already, and blend > it in with an overall scheme for associating URIs with each bit of > virtual space or virtual item. I'm not sure this is sufficient, but I > think it serves as a nice starting point. > > I think a small worked example would be helpful. This is intended to be > fairly accurate, but clearly not more than a thought experiment. > > Posit a virtual space which wishes to expose an administrative > interface which permits visitors with proper permission to change > several parameters of the physics engine. The current model of things > would require a cap and a custom bit of user interface, or user > interface exposed via some "in world" hook, such as a prim exposing a > web page, or a web page entirely disjoint from the inworld experience. > > Instead, we would provide a way for the region to advertize the > existence of the service to the client. I am, for example, imagining > either a capability exposed by the region, or a public URI/URL exposed by > the client. (Whether the approach is fully web centric, or blended in > with VWRAP style of capability access is clearly something worthy of > discussion) > > The client, on arrival to the region, fetches the URI, using content > negotiation and gets back a "cue" to display to the user that a service > is available. (Content negotiation let web based internationalization > and such simply happens) The cue is presented to the user as the client > sees fit, and if it is invoked, an associated URI launches the > user interface web service, which can be pre-fed with context, based > on the user. > > Now, this is doubly inappropriate for a programmatic approach. We neither > want to make programs screen scrape for content cues, nor do we want to > present them with a nice pretty user interface to manipulate. Thus, > a structured data path would be desirable. More on thinking about how > regions and scenegraph can expose APIs for performing tasks in a future post > > - David > ~ Zha > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap --=_alternative 00514E9E85257714_= Content-Type: text/html; charset="US-ASCII"
Its interesting.  I took Josh's presentation as part of an attempt to look at how we
avoid having to specify a ton of stuff when we get to the next round of effort, and
very much an attempt to stir some thought. In particular, Josh's proposed approach
is very much an effort to keep VWRAP *out* of the business of specifying stuff
it doesn't need to specify.

That said at the "Lets talk about how we might approach problems" level, it raised some
interesting questions. Questions I think need some love at the "Does this provide a framework
which would let us totally avoid a TON of work in the mainline of the workgroup" level.

The WHOLE point of Josh's proposal and my comments on it is to see if we can define
a simple model so that implementers of virtual space services (regions) can expose
proprietary extensions in a way which cues the consumer, and gets the protocol out of the way.

I think its not only enough for the group to define the basics, but the only way forward. But, that
actually means looking at patterns like "how do I associate my private service with
part of the scene I am serving"  The example I gave was explicitly described as "so how might
this work" not "We should specify this."

I think we can start to work out how regions ought to work in parallel with updating the base
getting teleport published and merging in the content we've all agreed needs merging. The
presentation Josh produced on the legacy protocols is at a high level of  lets start
thinking about this, as was my response. The ideal out come of that would be a
"Yes, this could work"or "Oh, no, it misses these three things, lets see how that would work"
as input into describing a very concrete, small set of building blocks which would allow
regions to standup proprietary services with web style user interfaces hosted by those
services (Nicely requiring zero work from VWRAP) and possibly, also showing how
to permit API style services to follow the same path.

- David
~ Zha



Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote on 04/28/2010 08:37:25 PM:

> [image removed]
>
> Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol  discussion
>
> Meadhbh Hamrick
>
> to:
>
> David W Levine
>
> 04/28/2010 08:42 PM
>
> Cc:
>
> vwrap
>
> so i feel your pain, david.
>
> but i want to ask, must the protocol specify ALL possible
> interfaces? isn't it possible for the VWRAP suite of protocols to
> specify a set of interfaces and resources for a bare minimum and
> leave the rest to implementers?
>
> in other words... i think we can get some radical agreement that
> authentication and teleportation and so forth are important to all
> virtual worlds. but we might have some argument that game script and
> land ownership interfaces are universally important.
>
> maybe it's enough in this working group to define the basics and
> have other features be proprietary extensions?
>
> this is one of the features of the OMG process i liked; people could
> extend "CORBA" all they wanted, but if they wanted their extensions
> to be part of the spec, they had to spend a few days in hotel bars
> lobbying other members to not object when it's discussed in the
> orbos meetings.
>
> in other words... would it kill us if we moved forward with what we
> seem to have agreed to in the chartering process, let people try
> several different solutions for annotation of objects in the virtual
> world, write a bunch of competing drafts, then retire to the hotel
> bar for a few days and come out with an agreement for how we handle
> different "extensions"?
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
>

> On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <dwl@us.ibm.com> wrote:
>
> As always, food for thought, probably partly baked.
>
> Josh Linden's presentation on the Linden Legacy Protocol
> raises the possibility that a substantial number of
> operations currently managed by the Linden Labs client be
> viewed as "out of scope" for VWRAP and exposed as "there is
> a URI/URL which provides access to a service to perform this
> task."
>
> Thus rather than including a set of LLIDL messages which define
> how to set parcel permissions, you would associate a "Here is a
> URI to invoke to get to a UI about this parcel"
>
> I would argue this solves roughly 1/3 of the problem. It makes it very
> easy for a deployed to provide a customer user interface, and it nicely
> reduces the amount of work needed to describe a useful protocol. I also
> said 1/3 because I think it misses two things. First, it begs the
> question(s) "What cues are needed to let the client know where things
> happen" and second, it misses the need to expose the attributes these
> interfaces would manage in a programmatic fashion.
>
> Effectively, the first problem is one of asking "How do we overlay the
> scene graph with UI cues." The more I think about it, the more I like
> the idea of solving this problem elegantly. In particular, the obvious
> design "This portion of the scenegraph or this broad area of virtual
> space" has "This URI" to invoke for more information seems pretty
> straightforward. How to cue things like "parcel boundaries" and "Has this
> property" is a little less obvious, but a good solution would be well
> worth having. Notice that this also allows some potentially elegant
> integration points. One could expose custom web page UIs as associated
> with Vendors, Buildings, portions of the ground, or any part of the
> scenegraph.
>
> The second problem is also one worth solving, tho its more difficult.
> I think it falls into two or three parts. The easy bit, is again, the
> "cue" issue. In short, how does one find out that there *is* structured
> data or an API associated with some portion of virtual space. At one
> level, the temptation is to say the web solves this already, and blend
> it in with an overall scheme for associating URIs with each bit of
> virtual space or virtual item. I'm not sure this is sufficient, but I
> think it serves as a nice starting point.
>
> I think a small worked example would be helpful. This is intended to be
> fairly accurate, but clearly not more than a thought experiment.
>
> Posit a virtual space which wishes to expose an administrative
> interface which permits visitors with proper permission to change
> several parameters of the physics engine. The current model of things
> would require a cap and a custom bit of user interface, or user
> interface exposed via some "in world" hook, such as a prim exposing a
> web page, or a web page entirely disjoint from the inworld experience.
>
> Instead, we would provide a way for the region to advertize the
> existence of the service to the client. I am, for example, imagining
> either a capability exposed by the region, or a public URI/URL exposed by
> the client. (Whether the approach is fully web centric, or blended in
> with VWRAP style of capability access is clearly something worthy of
> discussion)  
>
> The client, on arrival to the region, fetches the URI, using content
> negotiation and gets back a "cue" to display to the user that a service
> is available. (Content negotiation let web based internationalization
> and such simply happens) The cue is presented to the user as the client
> sees fit, and if it is invoked, an associated URI launches the
> user interface web service, which can be pre-fed with context, based
> on the user.
>
> Now, this is doubly inappropriate for a programmatic approach. We neither
> want to make programs screen scrape for content cues, nor do we want to
> present them with a nice pretty user interface to manipulate. Thus,
> a structured data path would be desirable. More on thinking about how
> regions and scenegraph can expose APIs for performing tasks in a future post
>
> - David
> ~ Zha
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
 --=_alternative 00514E9E85257714_=-- From morgaine.dinova@googlemail.com Thu Apr 29 10:45:45 2010 Return-Path: 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 66FC73A6B27 for ; Thu, 29 Apr 2010 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 bRki0ixx2UA4 for ; Thu, 29 Apr 2010 10:45:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6B4EC3A6BCB for ; Thu, 29 Apr 2010 10:45:35 -0700 (PDT) Received: by wyb35 with SMTP id 35so5538135wyb.31 for ; Thu, 29 Apr 2010 10:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=qkaBhgialZHZD0OVbhn3dmejBqcEQ5WupynIBAK+RI0=; b=pQCswX4GvE5swkZ+pmrdS9djUwW8qqM1ePoNC/F+1BYd1bqwwxn1dU5KwDpyRbTivA 3p37y0Tek24xaPIKQguJLfp47Yszg1TowAQb3nlv9tdN31yvxUYBN34bg4k1eASqtluV sicxjlNV1fBzs3qTCOyEg3VYKT2D2ImXC9d24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YI0YWZMg2w+UQWSRxQMzqyyNYLi5wfeLYMyzFWPE5xuQBnpEME8IgfLSQx+b8kD+o/ x35LWdnGEU3zlSBwXOi81WyAgPlvXQKGceW30rmBoSoxTVB/qIMrc4ed8Yzk9r2A8wIT 73XEDUUIrNnznRNj+fN4PvJXFGsbuOQlOY5uE= MIME-Version: 1.0 Received: by 10.216.163.202 with SMTP id a52mr4175512wel.81.1272563117841; Thu, 29 Apr 2010 10:45:17 -0700 (PDT) Received: by 10.216.25.6 with HTTP; Thu, 29 Apr 2010 10:45:17 -0700 (PDT) In-Reply-To: <4BD8D9F3.9000709@intel.com> References: <4BD8D9F3.9000709@intel.com> Date: Thu, 29 Apr 2010 18:45:17 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e654264697df2f048563b037 Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:45:45 -0000 --0016e654264697df2f048563b037 Content-Type: text/plain; charset=ISO-8859-1 I suspect that everyone would agree that we should find the smallest set of protocol requirements that covers the primary use cases effectively. There is of course a proviso implied there --- less common use cases must still be possible. Our protocol framework must be flexible and extensible enough to allow that. Ever since David gave us his document on the deployment patterns that are possible when services are decoupled, I think we have been charting a steady course through fairly calm waters, because we haven't needed to pick and choose deployments. Instead, our VWRAP protocol need only provide the *glue * to link decoupled services together, thus allowing a wide range of deployments to be chosen by individual VW service providers. That view provides a structural target for us: to make the VWRAP protocol an effective glue for services, in the same sense as the Unix shell is an effective glue for binding together Unix programs into multi-part applications. In our case, the protocol will bind together services to create a system of interoperating worlds. What we should do therefore is to enumerate the primary use cases consistent with our agreed charter, and to find the smallest amount of protocol glue that satisfies those requirements (and the charter), without cutting off other use cases. Different people will of course champion different use cases in accordance with their interests, which is perfectly fine and to be expected. The protocol needs to cover those particular use cases *well*. If our protocol is not flexible enough to cover even the WG's members' core deployments then it certainly won't be flexible enough to allow for less common use cases, and we will have failed. The core deployment patterns of most interest to me are those that allow tourism among multiple virtual worlds (the major use case for open worlds interop), so of course I will continue to champion those use cases. At the other end of the spectrum we have "walled garden" deployments, and others in between. As long as we ensure that services are fully decoupled, and as long as singletons are avoided (eg. for asset storage), we should not have a major problem in achieving this spectrum of goals within a very concise protocol. That said, the above is not enough. I agree with David entirely that a fundamental part of the interop problem concerns associating components of the perceived VW experience with services, programmatically. It is not enough merely to specify services. Clients have to be able to combine them programmatically to create the composite 3D audio/visual/textual mashup. If we don't provide a way of doing this then we have failed to deliver a protocol for interop. So let's find our core requirements based on our core use cases, and let's find a small but powerful mechanism that allows services to be combined in creating the VW mashup for interop, and we will have succeeded. Morgaine. ============================= On Thu, Apr 29, 2010 at 1:59 AM, John Hurliman wrote: > +1 to moving forward with a bare minimum set of requirements. The trap I > want to avoid is getting rough consensus that there are a ten different > areas where we need to standardize communication, but when it comes time to > actually doing the standards work it turns out only five of those areas are > relevant to the active participants. The other five areas receive a fair > dose of idle speculation, but otherwise go nowhere and stall the overall > process. > > If anyone identifies a specific resource (service endpoint, set of > endpoints, suite of bi-directional events, whatever) that they want to see > standardized, I would prefer to see it drafted / prototyped / alpha tested > before arguing that it should be officially sanctioned by VWRAP. > > John > > > On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote: > >> so i feel your pain, david. >> >> but i want to ask, must the protocol specify ALL possible interfaces? >> isn't it possible for the VWRAP suite of protocols to specify a set of >> interfaces and resources for a bare minimum and leave the rest to >> implementers? >> >> in other words... i think we can get some radical agreement that >> authentication and teleportation and so forth are important to all >> virtual worlds. but we might have some argument that game script and >> land ownership interfaces are universally important. >> >> maybe it's enough in this working group to define the basics and have >> other features be proprietary extensions? >> >> this is one of the features of the OMG process i liked; people could >> extend "CORBA" all they wanted, but if they wanted their extensions to >> be part of the spec, they had to spend a few days in hotel bars lobbying >> other members to not object when it's discussed in the orbos meetings. >> >> in other words... would it kill us if we moved forward with what we seem >> to have agreed to in the chartering process, let people try several >> different solutions for annotation of objects in the virtual world, >> write a bunch of competing drafts, then retire to the hotel bar for a >> few days and come out with an agreement for how we handle different >> "extensions"? >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> >> On Tue, Apr 27, 2010 at 2:41 PM, David W Levine > > wrote: >> >> >> As always, food for thought, probably partly baked. >> >> Josh Linden's presentation on the Linden Legacy Protocol >> raises the possibility that a substantial number of >> operations currently managed by the Linden Labs client be >> viewed as "out of scope" for VWRAP and exposed as "there is >> a URI/URL which provides access to a service to perform this >> task." >> >> Thus rather than including a set of LLIDL messages which define >> how to set parcel permissions, you would associate a "Here is a >> URI to invoke to get to a UI about this parcel" >> >> I would argue this solves roughly 1/3 of the problem. It makes it very >> easy for a deployed to provide a customer user interface, and it nicely >> reduces the amount of work needed to describe a useful protocol. I also >> said 1/3 because I think it misses two things. First, it begs the >> question(s) "What cues are needed to let the client know where things >> happen" and second, it misses the need to expose the attributes these >> interfaces would manage in a programmatic fashion. >> >> Effectively, the first problem is one of asking "How do we overlay the >> scene graph with UI cues." The more I think about it, the more I like >> the idea of solving this problem elegantly. In particular, the obvious >> design "This portion of the scenegraph or this broad area of virtual >> space" has "This URI" to invoke for more information seems pretty >> straightforward. How to cue things like "parcel boundaries" and "Has >> this >> property" is a little less obvious, but a good solution would be well >> worth having. Notice that this also allows some potentially elegant >> integration points. One could expose custom web page UIs as associated >> with Vendors, Buildings, portions of the ground, or any part of the >> scenegraph. >> >> The second problem is also one worth solving, tho its more difficult. >> I think it falls into two or three parts. The easy bit, is again, the >> "cue" issue. In short, how does one find out that there *is* structured >> data or an API associated with some portion of virtual space. At one >> level, the temptation is to say the web solves this already, and blend >> it in with an overall scheme for associating URIs with each bit of >> virtual space or virtual item. I'm not sure this is sufficient, but I >> think it serves as a nice starting point. >> >> I think a small worked example would be helpful. This is intended to be >> fairly accurate, but clearly not more than a thought experiment. >> >> Posit a virtual space which wishes to expose an administrative >> interface which permits visitors with proper permission to change >> several parameters of the physics engine. The current model of things >> would require a cap and a custom bit of user interface, or user >> interface exposed via some "in world" hook, such as a prim exposing a >> web page, or a web page entirely disjoint from the inworld experience. >> >> Instead, we would provide a way for the region to advertize the >> existence of the service to the client. I am, for example, imagining >> either a capability exposed by the region, or a public URI/URL >> exposed by >> the client. (Whether the approach is fully web centric, or blended in >> with VWRAP style of capability access is clearly something worthy of >> discussion) >> >> The client, on arrival to the region, fetches the URI, using content >> negotiation and gets back a "cue" to display to the user that a service >> is available. (Content negotiation let web based internationalization >> and such simply happens) The cue is presented to the user as the client >> sees fit, and if it is invoked, an associated URI launches the >> user interface web service, which can be pre-fed with context, based >> on the user. >> >> Now, this is doubly inappropriate for a programmatic approach. We >> neither >> want to make programs screen scrape for content cues, nor do we want to >> present them with a nice pretty user interface to manipulate. Thus, >> a structured data path would be desirable. More on thinking about how >> regions and scenegraph can expose APIs for performing tasks in a >> future post >> >> - David >> ~ Zha >> >> _______________________________________________ >> 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 > --0016e654264697df2f048563b037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suspect that everyone would agree that we should find the smallest set of= protocol requirements that covers the primary use cases effectively.=A0 Th= ere is of course a proviso implied there --- less common use cases must sti= ll be possible. Our protocol framework must be flexible and extensible enou= gh to allow that.

Ever since David gave us his document on the deployment patterns that a= re possible when services are decoupled, I think we have been charting a st= eady course through fairly calm waters, because we haven't needed to pi= ck and choose deployments.=A0 Instead, our VWRAP protocol need only provide= the glue to link decoupled services together, thus allowing a wide = range of deployments to be chosen by individual VW service providers.

That view provides a structural target for us:=A0 to make the VWRAP pro= tocol an effective glue for services, in the same sense as the Unix shell i= s an effective glue for binding together Unix programs into multi-part appl= ications.=A0 In our case, the protocol will bind together services to creat= e a system of interoperating worlds.

What we should do therefore is to enumerate the primary use cases consi= stent with our agreed charter, and to find the smallest amount of protocol = glue that satisfies those requirements (and the charter), without cutting o= ff other use cases.

Different people will of course champion different use cases in accorda= nce with their interests, which is perfectly fine and to be expected.=A0 Th= e protocol needs to cover those particular use cases well.=A0 If our= protocol is not flexible enough to cover even the WG's members' co= re deployments then it certainly won't be flexible enough to allow for = less common use cases, and we will have failed.

The core deployment patterns of most interest to me are those that allo= w tourism among multiple virtual worlds (the major use case for open worlds= interop), so of course I will continue to champion those use cases.=A0 At = the other end of the spectrum we have "walled garden" deployments= , and others in between.=A0 As long as we ensure that services are fully de= coupled, and as long as singletons are avoided (eg. for asset storage), we = should not have a major problem in achieving this spectrum of goals within = a very concise protocol.

That said, the above is not enough.

I agree with David entirely = that a fundamental part of the interop problem concerns associating compone= nts of the perceived VW experience with services, programmatically.=A0 It i= s not enough merely to specify services.=A0 Clients have to be able to comb= ine them programmatically to create the composite 3D audio/visual/textual m= ashup.=A0 If we don't provide a way of doing this then we have failed t= o deliver a protocol for interop.

So let's find our core requirements based on our core use cases, an= d let's find a small but powerful mechanism that allows services to be = combined in creating the VW mashup for interop, and we will have succeeded.=


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Apr 29, 2010 at 1:59 AM, John Hurliman <j= ohn.hurliman@intel.com> wrote:
+1 to moving forward with a bare minimum set of requirements. The trap I wa= nt to avoid is getting rough consensus that there are a ten different areas= where we need to standardize communication, but when it comes time to actu= ally doing the standards work it turns out only five of those areas are rel= evant to the active participants. The other five areas receive a fair dose = of idle speculation, but otherwise go nowhere and stall the overall process= .

If anyone identifies a specific resource (service endpoint, set of endpoint= s, suite of bi-directional events, whatever) that they want to see standard= ized, I would prefer to see it drafted / prototyped / alpha tested before a= rguing that it should be officially sanctioned by VWRAP.

John


On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:
=
so i feel your pain, david.

but i want to ask, must the protocol specify ALL possible interfaces?
isn't it possible for the VWRAP suite of protocols to specify a set of<= br> interfaces and resources for a bare minimum and leave the rest to
implementers?

in other words... i think we can get some radical agreement that
authentication and teleportation and so forth are important to all
virtual worlds. but we might have some argument that game script and
land ownership interfaces are universally important.

maybe it's enough in this working group to define the basics and have other features be proprietary extensions?

this is one of the features of the OMG process i liked; people could
extend "CORBA" all they wanted, but if they wanted their extensio= ns to
be part of the spec, they had to spend a few days in hotel bars lobbying other members to not object when it's discussed in the orbos meetings.<= br>
in other words... would it kill us if we moved forward with what we seem to have agreed to in the chartering process, let people try several
different solutions for annotation of objects in the virtual world,
write a bunch of competing drafts, then retire to the hotel bar for a
few days and come out with an agreement for how we handle different
"extensions"?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMe= adhbh@gmail.com
<mailto:OhMeadh= bh@gmail.com>



On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <dwl@us.ibm.com
<mailto:dwl@us.ibm.c= om>> wrote:


=A0 =A0As always, food for thought, probably partly baked.

=A0 =A0Josh Linden's presentation on the Linden Legacy Protocol
=A0 =A0raises the possibility that a substantial number of
=A0 =A0operations currently managed by the Linden Labs client be
=A0 =A0viewed as "out of scope" for VWRAP and exposed as "t= here is
=A0 =A0a URI/URL which provides access to a service to perform this
=A0 =A0task."

=A0 =A0Thus rather than including a set of LLIDL messages which define
=A0 =A0how to set parcel permissions, you would associate a "Here is = a
=A0 =A0URI to invoke to get to a UI about this parcel"

=A0 =A0I would argue this solves roughly 1/3 of the problem. It makes it v= ery
=A0 =A0easy for a deployed to provide a customer user interface, and it ni= cely
=A0 =A0reduces the amount of work needed to describe a useful protocol. I = also
=A0 =A0said 1/3 because I think it misses two things. First, it begs the =A0 =A0question(s) "What cues are needed to let the client know where= things
=A0 =A0happen" and second, it misses the need to expose the attribute= s these
=A0 =A0interfaces would manage in a programmatic fashion.

=A0 =A0Effectively, the first problem is one of asking "How do we ove= rlay the
=A0 =A0scene graph with UI cues." The more I think about it, the more= I like
=A0 =A0the idea of solving this problem elegantly. In particular, the obvi= ous
=A0 =A0design "This portion of the scenegraph or this broad area of v= irtual
=A0 =A0space" has "This URI" to invoke for more information= seems pretty
=A0 =A0straightforward. How to cue things like "parcel boundaries&quo= t; and "Has
=A0 =A0this
=A0 =A0property" is a little less obvious, but a good solution would = be well
=A0 =A0worth having. Notice that this also allows some potentially elegant=
=A0 =A0integration points. One could expose custom web page UIs as associa= ted
=A0 =A0with Vendors, Buildings, portions of the ground, or any part of the=
=A0 =A0scenegraph.

=A0 =A0The second problem is also one worth solving, tho its more difficul= t.
=A0 =A0I think it falls into two or three parts. The easy bit, is again, t= he
=A0 =A0"cue" issue. In short, how does one find out that there *= is* structured
=A0 =A0data or an API associated with some portion of virtual space. At on= e
=A0 =A0level, the temptation is to say the web solves this already, and bl= end
=A0 =A0it in with an overall scheme for associating URIs with each bit of<= br> =A0 =A0virtual space or virtual item. I'm not sure this is sufficient,= but I
=A0 =A0think it serves as a nice starting point.

=A0 =A0I think a small worked example would be helpful. This is intended t= o be
=A0 =A0fairly accurate, but clearly not more than a thought experiment.
=A0 =A0Posit a virtual space which wishes to expose an administrative
=A0 =A0interface which permits visitors with proper permission to change =A0 =A0several parameters of the physics engine. The current model of thin= gs
=A0 =A0would require a cap and a custom bit of user interface, or user
=A0 =A0interface exposed via some "in world" hook, such as a pri= m exposing a
=A0 =A0web page, or a web page entirely disjoint from the inworld experien= ce.

=A0 =A0Instead, we would provide a way for the region to advertize the
=A0 =A0existence of the service to the client. I am, for example, imaginin= g
=A0 =A0either a capability exposed by the region, or a public URI/URL
=A0 =A0exposed by
=A0 =A0the client. (Whether the approach is fully web centric, or blended = in
=A0 =A0with VWRAP style of capability access is clearly something worthy o= f
=A0 =A0discussion)

=A0 =A0The client, on arrival to the region, fetches the URI, using conten= t
=A0 =A0negotiation and gets back a "cue" to display to the user = that a service
=A0 =A0is available. (Content negotiation let web based internationalizati= on
=A0 =A0and such simply happens) The cue is presented to the user as the cl= ient
=A0 =A0sees fit, and if it is invoked, an associated URI launches the
=A0 =A0user interface web service, which can be pre-fed with context, base= d
=A0 =A0on the user.

=A0 =A0Now, this is doubly inappropriate for a programmatic approach. We =A0 =A0neither
=A0 =A0want to make programs screen scrape for content cues, nor do we wan= t to
=A0 =A0present them with a nice pretty user interface to manipulate. Thus,=
=A0 =A0a structured data path would be desirable. More on thinking about h= ow
=A0 =A0regions and scenegraph can expose APIs for performing tasks in a =A0 =A0future post

=A0 =A0- David
=A0 =A0~ Zha

=A0 =A0_______________________________________________
=A0 =A0vwrap mailing list
=A0 =A0vwrap@ietf.org<= /a> <mailto:vwrap@ie= tf.org>

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e654264697df2f048563b037-- From billwindwalker@rocketmail.com Fri Apr 30 05:24:36 2010 Return-Path: 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 450913A6C33 for ; Fri, 30 Apr 2010 05:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 SEm0brtuSVTs for ; Fri, 30 Apr 2010 05:24:33 -0700 (PDT) Received: from web111207.mail.gq1.yahoo.com (web111207.mail.gq1.yahoo.com [67.195.15.166]) by core3.amsl.com (Postfix) with SMTP id 520393A6C45 for ; Fri, 30 Apr 2010 05:23:29 -0700 (PDT) Received: (qmail 10857 invoked by uid 60001); 30 Apr 2010 12:23:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1272630193; bh=v9aajSx1HCyUy3wTpN+A3svLv5qpPRZ1OBv22BE4KVk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5BP0Ld1wWD/hTtkFw6QgwAE+0ldGyQI+NMylK+nDgGaVL7isZNmE0xPk0E90wxpQyww0+J7CTdMXNepUm6C5obTS+OI3qmieOjQIP9wv9tiadjSp48m/GbL7EVotyJOvzQ1G9TdAU79bQ5L+q2Cn6WT7nxG+8JYCfqmiXkvYgHM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Bo5btem3FtiBI58elHFXYnI7qEVKkm/7n4ngvibKV0Lk3OGX3cJhaYd109bTUqjNLMAJLch+NTsLIuWdbkozVjns6uzIfgy3rIvwGgyEATCU/r9lf6qjq0mfaq3daxC0w8cGwtZw/oo8E/oBxYlWlCMTBGY8t1n12J1WdwmyBdM=; Message-ID: <811517.9285.qm@web111207.mail.gq1.yahoo.com> X-YMail-OSG: pcWccuMVM1nehv5Nxe7.fFOOdJBgTpTTbngl5CfbGuLzMHx wAiVVnUcmb.NMnvQonPbOzkv3WYv5u0hlhloi3FViCqY9wCzmfrL6FTUKcFQ zTgFPdkZutyAyw7bFht3FMQ.bSPiD5Bux_mCMFjRkeVpxHIjziVmhBGDA3mZ EA7Nv6PxK1uqTzGHNeiXI4GDyB_lcTGUsAE6LzvhfM36d70JvlgRsgerfMnF Sq2Pu781kuJDPzfGsm_BwuW_vH8fcggJvL_Wr7YbC0hWBqT7auOgGP1fKE1U yEDBcsRS5npCD4E4hUzvMpRULkvYpehXFz02HOkr_ Received: from [75.30.221.64] by web111207.mail.gq1.yahoo.com via HTTP; Fri, 30 Apr 2010 05:23:13 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 References: <4BD8D9F3.9000709@intel.com> Date: Fri, 30 Apr 2010 05:23:13 -0700 (PDT) From: Bill Windwalker To: vwrap@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1013722029-1272630193=:9285" Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 12:24:36 -0000 --0-1013722029-1272630193=:9285 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am all for the Legacy Protocol as long as the Legacy Protocol will not ho= ld linden lab back for it starting to look like there is a great need for m= ore then one type of Viewer made by Linden Lab.=0AFor holding on to buggy w= hip in side a race car is not needed and thats how some of Legacy software = works.=0AFirst what will it cost later on ?=0Awill it hold the company back= ?=0Ahow many people wil use it?=0Aare there not other steps to be taken ?= =0A=0A=0A=0A=0A________________________________=0AFrom: Morgaine =0ATo: vwrap@ietf.org=0ASent: Thu, April 29, 2010 1:4= 5:17 PM=0ASubject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Pr= otocol discussion=0A=0AI suspect that everyone would agree that we should f= ind the smallest set of protocol requirements that covers the primary use c= ases effectively.=A0 There is of course a proviso implied there --- less co= mmon use cases must still be possible. Our protocol framework must be flexi= ble and extensible enough to allow that.=0A=0AEver since David gave us his = document on the deployment patterns that are possible when services are dec= oupled, I think we have been charting a steady course through fairly calm w= aters, because we haven't needed to pick and choose deployments.=A0 Instead= , our VWRAP protocol need only provide the glue to link decoupled services = together, thus allowing a wide range of deployments to be chosen by individ= ual VW service providers.=0A=0AThat view provides a structural target for u= s:=A0 to make the VWRAP protocol an effective glue for services, in the sam= e sense as the Unix shell is an effective glue for binding together Unix pr= ograms into multi-part applications.=A0 In our case, the protocol will bind= together services to create a system of interoperating worlds.=0A=0AWhat w= e should do therefore is to enumerate the primary use cases consistent with= our agreed charter, and to find the smallest amount of protocol glue that = satisfies those requirements (and the charter), without cutting off other u= se cases.=0A=0ADifferent people will of course champion different use cases= in accordance with their interests, which is perfectly fine and to be expe= cted.=A0 The protocol needs to cover those particular use cases well.=A0 If= our protocol is not flexible enough to cover even the WG's members' core d= eployments then it certainly won't be flexible enough to allow for less com= mon use cases, and we will have failed.=0A=0AThe core deployment patterns o= f most interest to me are those that allow tourism among multiple virtual w= orlds (the major use case for open worlds interop), so of course I will con= tinue to champion those use cases.=A0 At the other end of the spectrum we h= ave "walled garden" deployments, and others in between.=A0 As long as we en= sure that services are fully decoupled, and as long as singletons are avoid= ed (eg. for asset storage), we should not have a major problem in achieving= this spectrum of goals within a very concise protocol.=0A=0AThat said, the= above is not enough.=0A=0AI agree with David entirely that a fundamental p= art of the interop problem concerns associating components of the perceived= VW experience with services, programmatically.=A0 It is not enough merely = to specify services.=A0 Clients have to be able to combine them programmati= cally to create the composite 3D audio/visual/textual mashup.=A0 If we don'= t provide a way of doing this then we have failed to deliver a protocol for= interop.=0A=0ASo let's find our core requirements based on our core use ca= ses, and let's find a small but powerful mechanism that allows services to = be combined in creating the VW mashup for interop, and we will have succeed= ed.=0A=0A=0AMorgaine.=0A=0A=0A=0A=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AOn Thu, Apr = 29, 2010 at 1:59 AM, John Hurliman wrote:=0A=0A+1= to moving forward with a bare minimum set of requirements. The trap I want= to avoid is getting rough consensus that there are a ten different areas w= here we need to standardize communication, but when it comes time to actual= ly doing the standards work it turns out only five of those areas are relev= ant to the active participants. The other five areas receive a fair dose of= idle speculation, but otherwise go nowhere and stall the overall process.= =0A>=0A>If anyone identifies a specific resource (service endpoint, set of = endpoints, suite of bi-directional events, whatever) that they want to see = standardized, I would prefer to see it drafted / prototyped / alpha tested = before arguing that it should be officially sanctioned by VWRAP.=0A>=0A>Joh= n =0A>=0A>=0A>On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:=0A>=0A>so i feel= your pain, david.=0A>>=0A>>but i want to ask, must the protocol specify AL= L possible interfaces?=0A>>isn't it possible for the VWRAP suite of protoco= ls to specify a set of=0A>>interfaces and resources for a bare minimum and = leave the rest to=0A>>implementers?=0A>>=0A>>in other words... i think we c= an get some radical agreement that=0A>>authentication and teleportation and= so forth are important to all=0A>>virtual worlds. but we might have some a= rgument that game script and=0A>>land ownership interfaces are universally = important.=0A>>=0A>>maybe it's enough in this working group to define the b= asics and have=0A>>other features be proprietary extensions?=0A>>=0A>>this = is one of the features of the OMG process i liked; people could=0A>>extend = "CORBA" all they wanted, but if they wanted their extensions to=0A>>be part= of the spec, they had to spend a few days in hotel bars lobbying=0A>>other= members to not object when it's discussed in the orbos meetings.=0A>>=0A>>= in other words... would it kill us if we moved forward with what we seem=0A= >>to have agreed to in the chartering process, let people try several=0A>>d= ifferent solutions for annotation of objects in the virtual world,=0A>>writ= e a bunch of competing drafts, then retire to the hotel bar for a=0A>>few d= ays and come out with an agreement for how we handle different=0A>>"extensi= ons"?=0A>>=0A>>-cheers=0A>>-meadhbh=0A>>--=0A>>meadhbh hamrick * it's prono= unced "maeve"=0A>>@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com=0A= >> =0A>>=0A>>=0A>>=0A>>On Tue, Apr 27, 2010 at = 2:41 PM, David W Levine >=0A>>> w= rote:=0A>>=0A>>=0A>>=A0 =A0As always, food for thought, probably partly bak= ed.=0A>>=0A>>=A0 =A0Josh Linden's presentation on the Linden Legacy Protoco= l=0A>>=A0 =A0raises the possibility that a substantial number of=0A>>=A0 = =A0operations currently managed by the Linden Labs client be=0A>>=A0 =A0vie= wed as "out of scope" for VWRAP and exposed as "there is=0A>>=A0 =A0a URI/U= RL which provides access to a service to perform this=0A>>=A0 =A0task."=0A>= >=0A>>=A0 =A0Thus rather than including a set of LLIDL messages which defin= e=0A>>=A0 =A0how to set parcel permissions, you would associate a "Here is = a=0A>>=A0 =A0URI to invoke to get to a UI about this parcel"=0A>>=0A>>=A0 = =A0I would argue this solves roughly 1/3 of the problem. It makes it very= =0A>>=A0 =A0easy for a deployed to provide a customer user interface, and i= t nicely=0A>>=A0 =A0reduces the amount of work needed to describe a useful = protocol. I also=0A>>=A0 =A0said 1/3 because I think it misses two things. = First, it begs the=0A>>=A0 =A0question(s) "What cues are needed to let the = client know where things=0A>>=A0 =A0happen" and second, it misses the need = to expose the attributes these=0A>>=A0 =A0interfaces would manage in a prog= rammatic fashion.=0A>>=0A>>=A0 =A0Effectively, the first problem is one of = asking "How do we overlay the=0A>>=A0 =A0scene graph with UI cues." The mor= e I think about it, the more I like=0A>>=A0 =A0the idea of solving this pro= blem elegantly. In particular, the obvious=0A>>=A0 =A0design "This portion = of the scenegraph or this broad area of virtual=0A>>=A0 =A0space" has "This= URI" to invoke for more information seems pretty=0A>>=A0 =A0straightforwar= d. How to cue things like "parcel boundaries" and "Has=0A>>=A0 =A0this=0A>>= =A0 =A0property" is a little less obvious, but a good solution would be wel= l=0A>>=A0 =A0worth having. Notice that this also allows some potentially el= egant=0A>>=A0 =A0integration points. One could expose custom web page UIs a= s associated=0A>>=A0 =A0with Vendors, Buildings, portions of the ground, or= any part of the=0A>>=A0 =A0scenegraph.=0A>>=0A>>=A0 =A0The second problem = is also one worth solving, tho its more difficult.=0A>>=A0 =A0I think it fa= lls into two or three parts. The easy bit, is again, the=0A>>=A0 =A0"cue" i= ssue. In short, how does one find out that there *is* structured=0A>>=A0 = =A0data or an API associated with some portion of virtual space. At one=0A>= >=A0 =A0level, the temptation is to say the web solves this already, and bl= end=0A>>=A0 =A0it in with an overall scheme for associating URIs with each = bit of=0A>>=A0 =A0virtual space or virtual item. I'm not sure this is suffi= cient, but I=0A>>=A0 =A0think it serves as a nice starting point.=0A>>=0A>>= =A0 =A0I think a small worked example would be helpful. This is intended to= be=0A>>=A0 =A0fairly accurate, but clearly not more than a thought experim= ent.=0A>>=0A>>=A0 =A0Posit a virtual space which wishes to expose an admini= strative=0A>>=A0 =A0interface which permits visitors with proper permission= to change=0A>>=A0 =A0several parameters of the physics engine. The current= model of things=0A>>=A0 =A0would require a cap and a custom bit of user in= terface, or user=0A>>=A0 =A0interface exposed via some "in world" hook, suc= h as a prim exposing a=0A>>=A0 =A0web page, or a web page entirely disjoint= from the inworld experience.=0A>>=0A>>=A0 =A0Instead, we would provide a w= ay for the region to advertize the=0A>>=A0 =A0existence of the service to t= he client. I am, for example, imagining=0A>>=A0 =A0either a capability expo= sed by the region, or a public URI/URL=0A>>=A0 =A0exposed by=0A>>=A0 =A0the= client. (Whether the approach is fully web centric, or blended in=0A>>=A0 = =A0with VWRAP style of capability access is clearly something worthy of=0A>= >=A0 =A0discussion)=0A>>=0A>>=A0 =A0The client, on arrival to the region, f= etches the URI, using content=0A>>=A0 =A0negotiation and gets back a "cue" = to display to the user that a service=0A>>=A0 =A0is available. (Content neg= otiation let web based internationalization=0A>>=A0 =A0and such simply happ= ens) The cue is presented to the user as the client=0A>>=A0 =A0sees fit, an= d if it is invoked, an associated URI launches the=0A>>=A0 =A0user interfac= e web service, which can be pre-fed with context, based=0A>>=A0 =A0on the u= ser.=0A>>=0A>>=A0 =A0Now, this is doubly inappropriate for a programmatic a= pproach. We=0A>>=A0 =A0neither=0A>>=A0 =A0want to make programs screen scra= pe for content cues, nor do we want to=0A>>=A0 =A0present them with a nice = pretty user interface to manipulate. Thus,=0A>>=A0 =A0a structured data pat= h would be desirable. More on thinking about how=0A>>=A0 =A0regions and sce= negraph can expose APIs for performing tasks in a=0A>>=A0 =A0future post=0A= >>=0A>>=A0 =A0- David=0A>>=A0 =A0~ Zha=0A>>=0A>>=A0 =A0____________________= ___________________________=0A>>=A0 =A0vwrap mailing list=0A>>=A0 =A0vwrap@= ietf.org =0A>>=0A>>=A0 =A0https://www.ietf.org/mail= man/listinfo/vwrap=0A>>=0A>>=0A>>=0A>=0A>__________________________________= _____________=0A>vwrap mailing list=0A>vwrap@ietf.org=0A>https://www.ietf.o= rg/mailman/listinfo/vwrap=0A>=0A=0A=0A=0A --0-1013722029-1272630193=:9285 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am all for the Legacy Protocol as long as the Legacy= Protocol will not hold linden lab back for it starting to look like there = is a great need for more then one type of Viewer made by Linden Lab.
= =0A
For holding on to buggy whip in side a race car is not needed and t= hats how some of Legacy software works.
=0A
First what will it cos= t later on ?
=0A
will it hold the company back?
=0A
how m= any people wil use it?
=0A
are there not other steps to be taken ?=
=0A

=0A
=0A=0AFrom: Morgaine= <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
= Sent: Thu, April 29, 2010 1:45:17 PM
Subject: Re: [vwrap] Some thoughts on Josh's Linden= Lab Legacy Protocol discussion

I suspect that everyone would= agree that we should find the smallest set of protocol requirements that c= overs the primary use cases effectively.  There is of course a proviso= implied there --- less common use cases must still be possible. Our protoc= ol framework must be flexible and extensible enough to allow that.

E= ver since David gave us his document on the deployment patterns that are po= ssible when services are decoupled, I think we have been charting a steady = course through fairly calm waters, because we haven't needed to pick and ch= oose deployments.  Instead, our VWRAP protocol need only provide the gl= ue to link decoupled services together, thus allowing a wide range of d= eployments to be chosen by individual VW service providers.

That vie= w provides a structural target for us:  to make the VWRAP protocol an = effective glue for services, in the same sense as the Unix shell is an effe= ctive glue for binding together Unix programs into multi-part applications.=   In our case, the protocol will bind together services to create a sy= stem of interoperating worlds.

What we should do therefore is to enu= merate the primary use cases consistent with our agreed charter, and to fin= d the smallest amount of protocol glue that satisfies those requirements (a= nd the charter), without cutting off other use cases.

Different peop= le will of course champion different use cases in accordance with their int= erests, which is perfectly fine and to be expected.  The protocol needs to cover those particular use cases well.  If o= ur protocol is not flexible enough to cover even the WG's members' core dep= loyments then it certainly won't be flexible enough to allow for less commo= n use cases, and we will have failed.

The core deployment patterns o= f most interest to me are those that allow tourism among multiple virtual w= orlds (the major use case for open worlds interop), so of course I will con= tinue to champion those use cases.  At the other end of the spectrum w= e have "walled garden" deployments, and others in between.  As long as= we ensure that services are fully decoupled, and as long as singletons are= avoided (eg. for asset storage), we should not have a major problem in ach= ieving this spectrum of goals within a very concise protocol.

That s= aid, the above is not enough.

I agree with David entirely that a fun= damental part of the interop problem concerns associating components of the perceived VW experience with services, programmatically.  It i= s not enough merely to specify services.  Clients have to be able to c= ombine them programmatically to create the composite 3D audio/visual/textua= l mashup.  If we don't provide a way of doing this then we have failed= to deliver a protocol for interop.

So let's find our core requireme= nts based on our core use cases, and let's find a small but powerful mechan= ism that allows services to be combined in creating the VW mashup for inter= op, and we will have succeeded.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

=0A
On Thu, Apr 29, 2010 = at 1:59 AM, John Hurliman <john.hurliman@intel.com> wrote:
=0A+1 to moving forward with a bare= minimum set of requirements. The trap I want to avoid is getting rough con= sensus that there are a ten different areas where we need to standardize co= mmunication, but when it comes time to actually doing the standards work it= turns out only five of those areas are relevant to the active participants= . The other five areas receive a fair dose of idle speculation, but otherwi= se go nowhere and stall the overall process.

If anyone identifies a = specific resource (service endpoint, set of endpoints, suite of bi-directio= nal events, whatever) that they want to see standardized, I would prefer to= see it drafted / prototyped / alpha tested before arguing that it should b= e officially sanctioned by VWRAP.

John =0A
=0A
=0A

On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:
=0A=0A
=0A
=0A=
so i feel your pain, david.

but i want to ask, must the protoco= l specify ALL possible interfaces?
isn't it possible for the VWRAP suite= of protocols to specify a set of
interfaces and resources for a bare mi= nimum and leave the rest to
implementers?

in other words... i thi= nk we can get some radical agreement that
authentication and teleportati= on and so forth are important to all
virtual worlds. but we might have s= ome argument that game script and
land ownership interfaces are universa= lly important.

maybe it's enough in this working group to define the= basics and have
other features be proprietary extensions?

this i= s one of the features of the OMG process i liked; people could
extend "C= ORBA" all they wanted, but if they wanted their extensions to
be part of= the spec, they had to spend a few days in hotel bars lobbying
other mem= bers to not object when it's discussed in the orbos meetings.

in other words... would it kill us if we moved forward wi= th what we seem
to have agreed to in the chartering process, let people = try several
different solutions for annotation of objects in the virtual= world,
write a bunch of competing drafts, then retire to the hotel bar = for a
few days and come out with an agreement for how we handle differen= t
"extensions"?

-cheers
-meadhbh
--
meadhbh hamrick * it= 's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
<mailto:OhMeadhbh@gmail.com> =0A


On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <dwl@us.ibm.com
=0A
=0A
=0A
<mailto:dwl@us.ibm.com>> wrote:


  &nb= sp;As always, food for thought, probably partly baked.

   = Josh Linden's presentation on the Linden Legacy Protocol
   ra= ises the possibility that a substantial number of
   operation= s currently managed by the Linden Labs client be
   viewed as = "out of scope" for VWRAP and exposed as "there is
   a URI/URL= which provides access to a service to perform this
   task."<= BR>
   Thus rather than including a set of LLIDL messages whic= h define
   how to set parcel permissions, you would associate= a "Here is a
   URI to invoke to get to a UI about this parce= l"

   I would argue this solves roughly 1/3 of the problem= . It makes it very
   easy for a deployed to provide a customer user interface, and it nicely
   reduce= s the amount of work needed to describe a useful protocol. I also
 =  said 1/3 because I think it misses two things. First, it begs the   question(s) "What cues are needed to let the client know wher= e things
   happen" and second, it misses the need to expose t= he attributes these
   interfaces would manage in a programmat= ic fashion.

   Effectively, the first problem is one of as= king "How do we overlay the
   scene graph with UI cues." The = more I think about it, the more I like
   the idea of solving = this problem elegantly. In particular, the obvious
   design "= This portion of the scenegraph or this broad area of virtual
  &nbs= p;space" has "This URI" to invoke for more information seems pretty
&nbs= p;  straightforward. How to cue things like "parcel boundaries" and "Has
   this
   property" is a little less o= bvious, but a good solution would be well
   worth having. Not= ice that this also allows some potentially elegant
   integrat= ion points. One could expose custom web page UIs as associated
  &n= bsp;with Vendors, Buildings, portions of the ground, or any part of the
=    scenegraph.

   The second problem is also one= worth solving, tho its more difficult.
   I think it falls in= to two or three parts. The easy bit, is again, the
   "cue" is= sue. In short, how does one find out that there *is* structured
  &= nbsp;data or an API associated with some portion of virtual space. At one   level, the temptation is to say the web solves this already,= and blend
   it in with an overall scheme for associating URI= s with each bit of
   virtual space or virtual item. I'm not sure this is sufficient, but I
   think it serves as = a nice starting point.

   I think a small worked example w= ould be helpful. This is intended to be
   fairly accurate, bu= t clearly not more than a thought experiment.

   Posit a v= irtual space which wishes to expose an administrative
   inter= face which permits visitors with proper permission to change
  &nbs= p;several parameters of the physics engine. The current model of things
=    would require a cap and a custom bit of user interface, or use= r
   interface exposed via some "in world" hook, such as a pri= m exposing a
   web page, or a web page entirely disjoint from= the inworld experience.

   Instead, we would provide a wa= y for the region to advertize the
   existence of the service = to the client. I am, for example, imagining
   either a capability exposed by the region, or a public URI/URL
   expo= sed by
   the client. (Whether the approach is fully web centr= ic, or blended in
   with VWRAP style of capability access is = clearly something worthy of
   discussion)

   = ;The client, on arrival to the region, fetches the URI, using content
&n= bsp;  negotiation and gets back a "cue" to display to the user that a = service
   is available. (Content negotiation let web based in= ternationalization
   and such simply happens) The cue is pres= ented to the user as the client
   sees fit, and if it is invo= ked, an associated URI launches the
   user interface web serv= ice, which can be pre-fed with context, based
   on the user.<= BR>
   Now, this is doubly inappropriate for a programmatic ap= proach. We
   neither
   want to make programs screen scrape for content cues, nor do we want to
   = ;present them with a nice pretty user interface to manipulate. Thus,
&nb= sp;  a structured data path would be desirable. More on thinking about= how
   regions and scenegraph can expose APIs for performing = tasks in a
   future post

   - David
 = ;  ~ Zha

   _________________________________________= ______
   vwrap mailing list
   vwrap@ietf.org <mailto:vw= rap@ietf.org> =0A=0A
=0A
=0A

_______________________________________________
vwra= p mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap


=0A=0A --0-1013722029-1272630193=:9285--