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

[Morgaine <[e-mail]>]

On Mon, Apr 5, 2010 at 8:20 PM, Meadhbh Hamrick <[e-mail]> wrote:

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



Not so.

All you need to do in SL is to parse the single composite name field
containing embedded whitespace into component fields separated by the
whitespace, reject any parsing that yields more than two component fields,
and use these two component fields for SL's {firstname, lastname} tuple.

Such local interpretations of the single name field should most definitely
not be in the auth spec.


Morgaine.




=================================

On Mon, Apr 5, 2010 at 8:20 PM, Meadhbh Hamrick <[e-mail]> 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
>