Re: [vwrap] Removing first name / last name assumptions?
Meadhbh Hamrick <ohmeadhbh@gmail.com> Mon, 05 April 2010 20:41 UTC
Return-Path: <ohmeadhbh@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 15B8228C12C for <vwrap@core3.amsl.com>;
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
<vwrap@core3.amsl.com>; 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
<vwrap@ietf.org>; Mon, 5 Apr 2010 13:41:53 -0700 (PDT)
Received: by qyk11 with SMTP id 11so4348528qyk.13 for <vwrap@ietf.org>;
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: <BAY136-DS161108878D3ED4F1383E2FDC190@phx.gbl>
References: <62BFE5680C037E4DA0B0A08946C0933DCB738C13@rrsmsx506.amr.corp.intel.com>
<t2jb325928b1004051220i5f1d8f04od2602f26f758f3da@mail.gmail.com>
<CDB96FF3-A282-40B3-94D8-A9B6A00D8AF5@bbn.com>
<62BFE5680C037E4DA0B0A08946C0933DCB738C9B@rrsmsx506.amr.corp.intel.com>
<y2gb325928b1004051307u5f5e64d9zd18b70bfd8307d6a@mail.gmail.com>
<BAY136-DS161108878D3ED4F1383E2FDC190@phx.gbl>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
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: <o2lb325928b1004051341ib0b441bfidcf661fa0a15693b@mail.gmail.com>
To: Patnad Babii <djshag@hotmail.com>
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
<vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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 <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" 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" <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 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 >>>> <infinity@example.com >>>> >". >>>> >>>> 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 >>>> <john.hurliman@intel.com >>>> > > 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] Removing first name / last name assumptio… Hurliman, John
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Morgaine
- Re: [vwrap] Removing first name / last name assum… Richard Barnes
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Hurliman, John
- Re: [vwrap] Removing first name / last name assum… Richard Barnes
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Patnad Babii
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Hurliman, John
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Hurliman, John
- Re: [vwrap] Removing first name / last name assum… Hurliman, John
- Re: [vwrap] Removing first name / last name assum… Vaughn Deluca
- Re: [vwrap] Removing first name / last name assum… Morgaine
- Re: [vwrap] Removing first name / last name assum… Barry Leiba
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Dave CROCKER
- Re: [vwrap] Removing first name / last name assum… Morgaine
- Re: [vwrap] Removing first name / last name assum… Morgaine
- Re: [vwrap] Removing first name / last name assum… Christian Scholz
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Dzonatas Sol
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Dzonatas Sol
- Re: [vwrap] Removing first name / last name assum… Joshua Bell
- Re: [vwrap] Removing first name / last name assum… Meadhbh Hamrick
- Re: [vwrap] Removing first name / last name assum… Carlo Wood
- Re: [vwrap] Removing first name / last name assum… Morgaine
- Re: [vwrap] Removing first name / last name assum… Tammy Nowotny
- Re: [vwrap] Removing first name / last name assum… dyerbrookme@juno.com
- Re: [vwrap] Removing first name / last name assum… Patnad Babii
- Re: [vwrap] Removing first name / last name assum… dyerbrookme@juno.com
- Re: [vwrap] Removing first name / last name assum… Carlo Wood