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

[Meadhbh Hamrick <[e-mail]>]

do you have an account on SL with the name
"Reallylongfirstname......................................................
Dürst" ?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Mon, Apr 5, 2010 at 1:41 PM, Hurliman, John <[e-mail]> 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ürst". 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:[e-mail]]
>> Sent: Monday, April 05, 2010 1:29 PM
>> To: Hurliman, John
>> Cc: Richard Barnes; [e-mail]
>> 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/ * [e-mail]
>>
>>
>>
>> On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John
>> <[e-mail]> 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:[e-mail]]
>> >> Sent: Monday, April 05, 2010 1:00 PM
>> >> To: Meadhbh Hamrick
>> >> Cc: Hurliman, John; [e-mail]
>> >> 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 "[e-mail]" 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/ * [e-mail]
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes <[e-mail]>
>> >> > 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 <[e-mail]>"m>".
>> >> >>
>> >> >> 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
>> >> >>
>> >> >>
>> >
>> >
>