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

["Hurliman, John" <[e-mail]>]

"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
> >> >>
> >> >>
> >
> >