Re: [vwrap] Removing first name / last name assumptions?

[Vaughn Deluca <[e-mail]>]

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 <[e-mail]>wrote;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/ * [e-mail]
>
>
>
> On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii <[e-mail]> 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" <[e-mail]>
> > Sent: Monday, April 05, 2010 4:07 PM
> > To: "Hurliman, John" <[e-mail]>
> > Cc: <[e-mail]>
> > 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/ * [e-mail]
> >>
> >>
> >>
> >> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John <
> [e-mail]>
> >> 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:[e-mail]]
> >>>> Sent: Monday, April 05, 2010 12:39 PM
> >>>> To: Meadhbh Hamrick
> >>>> Cc: Hurliman, John; [e-mail]
> >>>> 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
> >>>> <[e-mail]
> >>>>  >".
> >>>>
> >>>> 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/ * [e-mail]
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John
> >>>> <[e-mail]
> >>>> > > 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
> >>>> >> [e-mail]
> >>>> >> https://www.ietf.org/mailman/listinfo/vwrap
> >>>> >>
> >>>> > _______________________________________________
> >>>> > vwrap mailing list
> >>>> > [e-mail]
> >>>> > https://www.ietf.org/mailman/listinfo/vwrap
> >>>
> >>> _______________________________________________
> >>> vwrap mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/vwrap
> >>>
> >> _______________________________________________
> >> vwrap mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/vwrap
> >>
> >
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>