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

[Meadhbh Hamrick <[e-mail]>]

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