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

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

No, this account is not on SL. It is on the SimianGrid Testing Agent Domain, hosted at <http://www.openmetaverstech.org/>.
John

> -----Original Message-----
> From: Meadhbh Hamrick [mailto:[e-mail]]
> Sent: Monday, April 05, 2010 1:45 PM
> To: Hurliman, John
> Cc: Richard Barnes; [e-mail]
> Subject: Re: [vwrap] Removing first name / last name assumptions?
> 
> 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
> >> >> >>
> >> >> >>
> >> >
> >> >
> >