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

From: "Hurliman, John" <[email-masked]>
Date: Mon, 5 Apr 2010 12:39:41 -0600

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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 12:20:08 -0700

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/ * [email-masked]

On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John <[email-masked]> wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Morgaine <[email-masked]>
Date: Mon, 5 Apr 2010 20:33:48 +0100

> 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 <[email-masked]> 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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Apr 2010 15:38:31 -0400

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 <[email-masked] 
 >".

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:

> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John <[email-masked] 
> > 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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 12:46:42 -0700

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

On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes <[email-masked]> 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 <[email-masked]>".
>
> 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
>
>

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 5 Apr 2010 13:53:51 -0600

Agreed. My current agent domain and region domain implementations treat names as opaque strings, and when it comes time to transition from the VWRAP interop protocol to the LLUDP client/server protocol I parse "First Last" into "First" and "Last". Are we seriously considering taking this discussion off the table because it would be too difficult for Linden Lab to change their AD/RD code to parse { "display_name": "First Last" }? Last time I checked, Linden Lab has not contributed any AD/RD code. IBM and the Open Metaverse Foundation are the ones writing all of the code for this, so if we want to talk about the hardships of organizations interested in making this a success let's ask them.

John

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 12:39 PM
> To: Meadhbh Hamrick
> Cc: Hurliman, John; [email-masked]
> Subject: Re: [vwrap] Removing first name / last name assumptions?
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Apr 2010 15:59:40 -0400

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 "[email-masked]" 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:

>> "client
>>>> name / last

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 13:07:15 -0700

no. we're proposing taking it off the table because there is a very
high likelihood that are valid first and/or last names in a particular
implementation that include spaces and periods. this is the reason we
came up with having first_name and last_name as separate strings in
the transfer syntax, and not a single string identifying the avatar's
name.

why do we need to REMOVE support for Second Life from this protocol?

also... why do we need to define a display name when logging into the
agent domain? shouldn't we specify one when we're rezzing an agent in
a region?

i'm hip to adding it if there's a need, but please don't remove
support for things required for other people's implementations.

On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John <[email-masked]> wrote:
>>  >".

---

From: "Patnad Babii" <[email-masked]>
Date: Mon, 5 Apr 2010 16:17:48 -0400

Some of the people in this list seem to believe that LL code is god 
re-incarnate.

Those kind of comments seem to have hold you back for a great deal of time 
already.

Those guys, John and others, don't want to remove "support" of second life 
in the protocol. They want to create a generic protocol that LL can (if they 
really wish..) use to connect to other worlds. So some adaptation will be 
needed from LL side also. Like first name / last name implementation, it can 
make sense for LL but for all the rest of the internet it doesn't, look at 
facebook for example (one great competitor isn't it...) they're not using 
firstname / lastname for login but some guys at LL think its the best way to 
do it.. well.. those guys might find out their way isn't the best after all 
(maybe they will only find out when a whole new metaverse will be created 
using VWRAP and LL is falling behind.. who knows).

Just my 2 cents, good work guys at Intel and IBM i'll always support your 
effort!

--------------------------------------------------
From: "Meadhbh Hamrick" <[email-masked]>
Sent: Monday, April 05, 2010 4:07 PM
To: "Hurliman, John" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [vwrap] Removing first name / last name assumptions?

>> Agreed. My current agent domain and region domain implementations treat 
>> names as opaque strings, and when it comes time to transition from the 
>> VWRAP interop protocol to the LLUDP client/server protocol I parse "First 
>> Last" into "First" and "Last". Are we seriously considering taking this 
>> discussion off the table because it would be too difficult for Linden Lab 
>> to change their AD/RD code to parse { "display_name": "First Last" }? 
>> Last time I checked, Linden Lab has not contributed any AD/RD code. IBM 
>> and the Open Metaverse Foundation are the ones writing all of the code 
>> for this, so if we want to talk about the hardships of organizations 
>> interested in making this a success let's ask them.
>>
>> John
>>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 13:25:19 -0700

VWRAP is a protocol intended to support some legacy implementations
like OpenSim and Second Life. in at least one of these implementations
there are first and or last names that somehow managed to get spaces
and periods (and if i remember correctly, some commas got in there
too.)

if we wanted to construct an entity identifier by concatenating the
first name, a separator and a last name, we would have to find a
separator that was not currently in use.

imagine the case of having the first name "le roy" and the last name
of "barr", if we used a blank as a separator, our identifier would be
"le roy barr". when it came time to parse this, there would be an
ambiguity as to whether the first name was "le" and the last name "roy
barr" or the first name "le roy" and the last name "barr".

so rather than cancel these accounts or rename them, we created an
optional identifier in the protocol that used two distinct strings to
identify the first and last names.

in the future, Second Life COULD use single string identifiers like
the examples you give below, but it currently only supports first /
last authentication.

it is likely that before SL uses single string IDs to identify users,
they will simply add a VWRAP interface to the existing implementation.
an implementation that needs both a first name and a last name.

while i agree with you that it would be preferential to have a single
string identifier (which is why we're having this discussion),
REQUIRING it's use would REQUIRE Linden to invest a fair amount of
effort before any return on supporting the standard would be realized.

by defining two identifiers (or using an array for identifiers and LL
telling everyone "we map that as first name and last name") and giving
deployers the choice of which to use, we can have a protocol that will
be deployed more quickly by a large virtual world. deploying faster
means we'll get experience faster and will be able to potentially
modify the standard to prevent us from specifying ourselves into a
corner.

please remember, there is absolutely NOTHING in the spec that REQUIRES
an authentication service in an agent domain to support the "two
string identifier" use case. the requirement is... if you use two
distinct strings to identify an agent, you must do it in a way that
adheres to whatever specification we come up with here for two string
identifiers.

may i ask which implementation has the requirement that identifiers
used in authentication NOT use two distinct strings?

-cheers
-meadhbh

On Mon, Apr 5, 2010 at 12:59 PM, Richard Barnes <[email-masked]> wrote:
> 1. I have an agent/account with vwrap.example.com, which has assigned me the
> identifier "[email-masked]" 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"
>
> 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.
> 2. VWRAP layer stores binding between VWRAP ID and SL name for repeat logins
>>> display
>>> the
>>>> On Mon, Apr 5, 2010 at 11:39 AM, Hurliman, John
>>>> <[email-masked]>
>>>> wrote:
>>>>>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 13:29:09 -0700

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?

On Mon, Apr 5, 2010 at 1:11 PM, Hurliman, John <[email-masked]> 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
>
>> Sent: Monday, April 05, 2010 1:00 PM
>> To: Meadhbh Hamrick
>> <[email-masked]

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 5 Apr 2010 14:11:59 -0600

John

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 13:41:28 -0700

i've seen linden's code up close. i can guarantee you i do not believe
it is god incarnate.

also. please do not visit my motivations. i do not tell you your
reason for disagreeing with me. please do not try to tell me what my
motivations are.

since it wasn't clear the first time, let's go over it once more.

we have a protocol that allows people to use a single string to
identify a user for the purposes of authentication / authorization or
two strings to identify the user.

we have two existing implementations from organizations who have
stated they would like to use this protocol. both use two strings at
the moment. both COULD be converted to use a single identifier, and
probably should, but one of them has the problem that the data is not
"clean" and it would be difficult to find a programmatic mechanism to
convert two strings to a single string without ambiguity.

we COULD add a server in the middle that maps old SL style names to
new single string identifiers, but this would require engineering
effort on the two existing systems.

or we could simply say, use a two string identifier or a single string
identifier (your choice) and then be about our merry way.

Patnad, i'm sorry you feel VWRAP is falling behind when we have a
discussion about people's existing requirements. as mentioned in the
charter, the VWRAP working group is NOT an effort to solve the general
problem of virtual world interoperability. it is an effort to solve
interoperability between systems that cooperate to present a certain
style of virtual world.

the MMOX mailing list is still active and is the place for discussions
about interoperability between an arbitrary pair of virtual worlds.

-thx
-meadhbh

On Mon, Apr 5, 2010 at 1:17 PM, Patnad Babii <[email-masked]> wrote:
>>> names as opaque strings, and when it comes time to transition from the VWRAP
>>> interop protocol to the LLUDP client/server protocol I parse "First Last"
>>> into "First" and "Last". Are we seriously considering taking this discussion
>>> off the table because it would be too difficult for Linden Lab to change
>>> their AD/RD code to parse { "display_name": "First Last" }? Last time I
>>> checked, Linden Lab has not contributed any AD/RD code. IBM and the Open
>>> Metaverse Foundation are the ones writing all of the code for this, so if we
>>> want to talk about the hardships of organizations interested in making this
>>> a success let's ask them.
>>>
>>> John
>>>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 13:45:09 -0700

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

On Mon, Apr 5, 2010 at 1:41 PM, Hurliman, John <[email-masked]> 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
>
>> From: Meadhbh Hamrick [mailto:[email-masked]]
>> Sent: Monday, April 05, 2010 1:29 PM
>> To: Hurliman, John
>> Cc: Richard Barnes; [email-masked]
>> > 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
>> >
>> >> >> The only reason you would need to have a (Firstname, Lastname)
>> pair
>> >> >> in the
>> >> >> party I've never met before, and the new region greets me by
>> first
>> >> >> name.  Is
>> >> >>> while this is not an effort to "bless" linden's Second Life
>> model
>> >> >>> and
>> >> >>> authentication. if you want to use a single opaque identifier,
>> use
>> >> >>> the
>> >> >>> in this proposal, the data used to identify the user is an
>> array.
>> >> >>> for
>> >> >>> the account identifier goes back to what it was supposed to be:
>> a
>> >> >>> way
>> >> >>> identifying an account, they communicate the client's interest
>> int
>> >> >>> he

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 5 Apr 2010 14:41:39 -0600

John

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 5 Apr 2010 14:47:44 -0600

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

> Sent: Monday, April 05, 2010 1:45 PM
> To: Hurliman, John
> > 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
> >
> >> >> 1. When an unknown ID shows up, ask them to pick a new SL name
> (in
> >> UI)
> >> >> > those identifiers at the moment, and it's unknown when it will
> in
> >> the
> >> >> > future.
> >> >> >
> >> >> > but then what do you do with names with dots in them? change
> them
> >> in
> >> >> > i think it's an INSANELY GREAT idea to define an entity
> identifier
> >> >> for
> >> >> > there is a requirement that we carry information in a way in
> which
> >> >> the
> >> >> > On Mon, Apr 5, 2010 at 12:38 PM, Richard Barnes
> <[email-masked]>
> >> >> > wrote:
> >> >> >> identifier" field where you could put an arbitrary name chosen
> by
> >> >> the
> >> >> >> *protocol* is if you expected a need for names to be used in
> that
> >> >> way
> >> >> >> critical use case.  See Gmail's "first name extraction" in
> Inbox
> >> >> >> message
> >> >> >> summaries.)
> >> >> >>
> >> >> >> --Richard
> >> >> >>
> >> >> >>
> >> >> >>> authentication (which is currently used by both SL and
> OpenSim)
> >> >> will
> >> >> >>> 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
> >> >> >>> the current draft allows for EITHER an account identifier or
> an
> >> >> >>> agent
> >> >> >>> account identifier. if you want to use a first name / last
> name,
> >> >> use
> >> >> >>> as it stands now, the account identifier was intended to be
> used
> >> in
> >> >> >>> conjunction with agent identifiers in case a user had
> multiple
> >> >> >>> avatars
> >> >> >>> systems like second life and OpenSim that want to use two
> names
> >> to
> >> >> >>> c. sure, i'm hip to dropping the last name / first name
> thing,
> >> but
> >> >> >>>> name assumptions from the avatar identifier, but it looks
> like
> >> >> that
> >> >> >>>> conversation didn't carry over to the mailing list. Does
> anyone
> >> >> >>>> know exactly

---

From: Vaughn Deluca <[email-masked]>
Date: Tue, 6 Apr 2010 00:21:20 +0200

I agree with meadhbh on this one.  I have not seen any good arguments
explaining why a first name/last name option would be harmful.
--Vaughn

On Mon, Apr 5, 2010 at 10:41 PM, Meadhbh Hamrick <[email-masked]>wrote:

> >> On Mon, Apr 5, 2010 at 12:53 PM, Hurliman, John <
> [email-masked]>
> >> wrote:
> >>>

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Apr 2010 04:21:24 +0100

Vaughn, Internet protocols aren't designed at the IETF on the basis of
favoring some existing provider.  The Mission Statement and Tao of the IETF
place a higher burden than that on us.  We're working to the benefit of all
the users on the Internet, and that's why we try to make protocols that are
generic and free of special cases.

SL's two-part name is that service's particular choice, but it is not
generic, nor is it helpful to the world as a whole.  A single field is
generic, because it can hold any number of words, and whitespace is the
normal separator in human writing.

We're proposing something better than the legacy service, rather than merely
accepting something that is "not harmful".  And one might validly reason
that a 2-part name is indeed "harmful" to the genericity of the protocol,
because it is a special case that may not apply to others.

In any event, parsing a single field and accepting only 2-word names within
it is such a trivial task that I'm surprised to find anyone arguing
otherwise.  Some providers may allow only single words, some two, others may
allow only three words of which the first is a title, and others may allow
an arbitrary number of words as is common in gaming worlds.  The generic
approach is to use a single field in the protocol and to parse it as
required for the local service.

Note that Joshua Linden wrote a very thoughtful post on this subject last
June, noting that {firstname, lastname} is just "*a quirk of Second Life,
and not necessarily something that every OGP provider must use*" --
here<http://www.ietf.org/mail-archive/web/ogpx/current/msg00088.html>
.

That's a perfectly fine quirk for SL, but quirks have no place in the
protocol when we have the better option of a generic single name field.  SL
can just parse the single field for words and reject anything except
two-word names.  It's not rocket science, and we have far tougher problems
than that to solve ahead of us.

Morgaine.

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Apr 2010 00:32:08 -0400

> why do we need to REMOVE support for Second Life from this protocol?

Well, here's the thing:

First: I've spent a lot of years designing protocols, and I think it's
a terrible idea to define a specific artifact of a specific
implementation in a new protocol.  We've done it many times before,
and it's pretty much always caused problems.  Sometimes those problems
eventually worked themselves out, but I'm quite sure it was a mistake
to go there.

Second: I don't see it as a question of "removing support for Second
Life", but one of looking at alternatives that are protocol-clean and
allow everyone to work with it.  And, by the way, I don't consider two
separate identifier fields, from which you're meant to pick which you
want to use, to be "protocol-clean".

Why not define the agent identifier in a self-parsing way?  Something
like this should work (written in ABNF):

   agent-identifier := delim 1*(id-part delim)
   id-part = string
   delim = 1char

...where the idea is that the delimiter is a single character that
appears as the first character (so it's self-identifying), and then
between ID parts.  The implementation would pick a character (which
could be a non-printable code point, such as 0x00 or 0x01, if
necessary) that doesn't appear in any identifier part.  Here's a
sampling of agent-identifiers, each within quotes just to make it
clear where they start and end:
   " Joshua Linden "
   ".Joshua.Linden."  (another way to represent the same thing)
   "/Joshua/Linden/"  (a third)
   "XJoshuaXLindenX"  (a fourth)
   " Melanie "  (an identifier with just one part)
   "rMelanier"  (the same, in another representation)
   ".Melanie."  (or less weirdly)
   " Barak Hussein Obama "   (here's one with three parts)
   "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit
if you're old enough to know who he is)
   "~le roy~barr~"  (Meadhbh's example with an embedded blank)

This scheme only adds two characters to the identifier (the leading
and trailing delimiter, and we *could* eliminate the trailing one, if
people prefer, by defining agent-identifier as "1*(delim id-part)"...
I like having it), and seems to solve everyone's problem.

Barry, as participant

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Apr 2010 22:01:44 -0700

well. it would be good form if we could use vwrap with second life,
considering the fact that many people want to use it in that way.

the problem is that it's not entirely certain which delimiter should
be used since the SL names database is "dirty" with respect to common
delimiters.

the reason the protocol includes two distinct strings in the transfer
syntax is so that the transfer syntax will operate to differentiate
the two names.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Apr 2010 22:03:11 -0700

On 4/5/2010 9:32 PM, Barry Leiba wrote:
> And, by the way, I don't consider two

Barry, you just want to take the fun out of protocol processing.

Which is another way of my saying +1...

> like this should work (written in ABNF):

Within the larger system for which this protocol will operate, what 
participating engines need to "understand" the internal structure of the value? 
  If it is only the creator of the value -- that is, if the protocol and other 
engines merely see the string as a literal token to be returned to its 
originator -- then it isn't parsed or internally delimited by the protocol. 
It's an opaque string and its originator can define parsing rules however they 
see fit, since they are the only ones who will in fact be seeing its internal 
structure.

If the string is to be parsed by others, what is the purpose of the parsing? 
That is, what are the other engines going to do with the sub-structure to the 
value?  The answer to this tends to guide choices about fixed vs. variable 
parsing rules.

If this string is really going to get into the real world firstname/lastname 
game and is required to operate within the larger Internet, it's going to have 
to support dramatically more semantic complexity than just two simple strings.

My impression, however, is that this is a global unique identifier, where human 
names are convenient choices, when they work.  That leaves open the obvious 
problem of when they don't, since names are not globally unique.

Assuming other protocol engines and participants do need to see that 
substructure, it's usually best to define a single, canonical syntactic 
structure and have all originators and parsers map to/from it for their local 
encodings.  So the protocol defines a fixed means of delimiting internal 
structure, as well as a way of "quoting" the delimiter, if needed.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Apr 2010 07:00:38 +0100

> considering the fact that many people want to use it in that way.
I'm not aware of any Linden suggesting that the single-field design would
make VWRAP not usable with Second Life.  Perhaps we could leave it to them
to comment.

> be used since the SL names database is "dirty" with respect to common

The state of the SL names database is not the primary driving force for the
design of VWRAP protocols.

Morgaine.

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

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Apr 2010 07:48:22 +0100

Barry, good suggestions!

+1 for self-describing encodings in general;  and

+1 for this particular delimiter encoding, which is hard to beat for
clarity, brevity, and efficiency.  It should have a name! :-)

Regarding the issue of the trailing delimiter, I like the Robustness
Principle <http://en.wikipedia.org/wiki/Robustness_principle> (although
perhaps referring to RFC 760 and RFC 1122 would be more suitable here :P),
so I would recommend accepting the trailing delimiter or its absence as
equivalent valid terminations.  For the same reason, I would also recommend
accepting repeated delimiters as equivalent to single delimiters (unless you
specifically want to allow null fields), otherwise delimiter characters are
bound to end up in names when parsing is done poorly. :-)

Morgaine.

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

---

From: Christian Scholz <[email-masked]>
Date: Tue, 06 Apr 2010 11:08:26 +0200

Hi!

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

I still don't really understand why you aren't levering existing
specification like OpenSocial/PortableContacts:

http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Person
http://portablecontacts.net/draft-spec.html

Shouldn't they have already most of the things defined and you would
gain additional interoperability by using it?

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 14:12:28 +0200

> separator that was not currently in use.

Yup, a space thus.

"Firstname Lastname"

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 14:19:02 +0200

> why do we need to REMOVE support for Second Life from this protocol?

Second Life would remove itself imho.

The point is that the "agent login ID" can be anything, should be allowed
to be anything. Surely Linden Lab can come up with a way to put their
login stuff in a single string? That is NOT too difficult at ALL.
You will have to write loads of new code to support VWRAP. It will
probably be a very special and new vwrap.cpp file. So, just implement
that this new code will understand "Firstname Lastname" as a single
(input) string and have it output two strings "Firstname" and "Lastname"
and off you go.

What is proposed so far is to encode it as "Firstname Lastname" (just
catenate the two, as is done on for example
https://jira.secondlife.com/cas/login

Can you explain why the login interface of the jira has no problems
with this, but Linden Lab claims it will be forced out of VWRAP?

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 14:33:05 +0200

> convert two strings to a single string without ambiguity.

I don't believe this.

Does Second Life have *ANY* login name that has a space in
it's LAST name? If so, please tell me which and allow me to
find it in the People Search in world.

If not, then your problem is solved: search for the first
space from the back, that is your separator.

Here is the implementation, let me know if you need a special
license or a transfer of copyright.

#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[])
{
  if (argc != 2)
  {
    printf("Usage: %s agent-ID-string\n", argv[0]);
    return;
  }
  char* space = strrchr(argv[1], ' ');
  if (!space)
  {
    printf("This is not a valid Second Life name\n");
    return;
  }

  /* Start of EXTRA code LL needs to add to support VWRAP */
  size_t len = space - argv[1];
  char* firstname = argv[1];
  argv[1][len] = 0;
  char* lastname = firstname + len + 1;
  /* End of EXTRA code LL needs to add to support VWRAP */

  printf("Firstname = \"%s\", lastname = \"%s\"\n", firstname, lastname);
}

Example output:

$ ./a.out "abcde,fghi.jkl Linden"
Firstname = "abcde,fghi.jkl", lastname = "Linden"

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 15:01:39 +0200

> I like having it), and seems to solve everyone's problem.

It solves Linden Labs "problem". I mean, you are not suggesting that
this should be part of VWRAP right?

VWRAP doesn't need to specify how each login server will decode
the AgentID string. That can be different from provider to provider.

Since Meadhbh kept saying that the LL database is "dirty" so that
not ANY single delimiter will do (they have first and last names
that contain any of the 256 binary values of character), how about
encoding it like this:

[length][firstname][lastname]

where [length] is the first byte (8 bit) and represents
the length of the firstname. For example:

"\05CarloWood"

That would allow for ANY characters anywhere in both first- and
lastname.

Implementation example (in C++):

#include <iostream>

int const maxnamelen = 32;      // Must be less than 256.

int main()
{
  std::string const input_firstname = "Carlo";
  std::string const input_lastname = "Wood";

  // Encode LL name pair to agentID for VWRAP.
  std::string agentID;
  agentID = (unsigned char)input_firstname.length();    // Never 0.
  agentID += input_firstname;
  agentID += input_lastname;

  // Decode VWRAP agentID to LL name pair.
  size_t firstlen = agentID[0];
  std::string firstname = agentID.substr(1, firstlen);
  std::string lastname = agentID.substr(firstlen + 1, agentID.length() - 1 - firstlen);

  std::cout << "Firstname = \"" << firstname << "\"; lastname = \"" << lastname << "\"." << std::endl;
}

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 15:07:43 +0200

I don't think that adding ALSO the religion, sexual orientation,
names of children and job interests to the VWRAP specs will solve
much. Note we are talking about the agentID - not the complete
blue print of someone private Real Life data.

EVEN if some agent login provider wanted to put lot of (private)
data in the agentID string, then that is his problem (like it
is Linden Lab's "problem" to catenate their first/last name
fields and later decode those again) and how to do that has
no place in VWRAP imho.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 06 Apr 2010 07:32:26 -0700

Barry Leiba wrote:
>  Here's a
Another suggestion, if one used XML like tags:

<first>Barak</first> Hussein <last>Obama</last>

Then the string can be escaped into the name field. For those that don't 
want first/last, they just skip the tags. For those that only want 
first/last, they pull the text only within with first/last tags.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 07:17:27 -0700

because we are building a normative standard and we need to reference
existing standards from recognized SDOs, not draft documents without
copyright notices whose IPR status is unknown.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 07:28:08 -0700

not sure what you're going for here...

the example is not valid XML, but i think your recommendation is
simply to use XML-like tags in the string that gets put inside the
transfer encoding,

so if you encoded it with JSON it would be something like:

{ "name": "<first>simon</first><last>le bon</last>"}

or with XML, it would be encoded as:

<llsd>
  <map>
    <key>name</key>
    <string>&lt;first&gt;simon&lt;/first&gt;&lt;last&gt;le
bon&lt;/last&gt;</string>
  </map>
</llsd>

?

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 06 Apr 2010 08:04:14 -0700

It's a valid XML snipplet, I just didn't include the full wrap of LLSD 
or JSON as you have. You still need to keep the space between the tags, 
or else:

"<first>simon</first><last>le bon</last>"

Would look like this without tags:

"simonle bon"

Which is not desired, so it would need to be:

"<first>simon</first> <last>le bon</last>"

Where there is a space between "</first>" and "<last>" tags.

Better example, if someone simply dropped the tags on this input:

{ "name": "<first>Barak</first> Hussein <last>Le Obama</last>" }

They would get this:

{ "name": "Barak Hussein Le Obama" }

If they only pulled the text from the tags from the input, they would get:

{ "first": "Barak", "last": "Le Obama" }

This way the initial input "name" satisfies both desires for a single 
string name and for first/last significance names. I kept "Le Obama" 
above as an example with a last name with a space in it.

This could further be applied internationally where people have 
different order for family names, so for Mr. Yao (basketball player):

{ "name": "<last>Yao</last> <first>Ming</first>" }

And when you drop the tags you get the names in the right order:

{ "name": "Yao Ming" }

Meadhbh Hamrick wrote:
>>> �Here's a
>>> � " Joshua Linden "
>>> � ".Joshua.Linden." �(another way to represent the same thing)
>>> � "/Joshua/Linden/" �(a third)
>>> � "XJoshuaXLindenX" �(a fourth)
>>> � " Melanie " �(an identifier with just one part)
>>> � "rMelanier" �(the same, in another representation)
>>> � ".Melanie." �(or less weirdly)
>>> � " Barak Hussein Obama " � (here's one with three parts)
>>> � "+Peter+Blair+Dennis+Bernard+Noone+" (a five-part one; extra credit
>>> � "~le roy~barr~" �(Meadhbh's example with an embedded blank)
>>>
>>>
>>>

---

From: Joshua Bell <[email-masked]>
Date: Tue, 6 Apr 2010 08:51:50 -0700

Speaking for Linden:

(1) For the purposes of VWRAP interop, it is acceptable to us to assume that
a human readable agent identifier ("name") for Second Life can be coerced to
and from a single string field. Today, SL firstname/lastname pairs are
constrained to a subset of ASCII that disallows characters such as periods
and spaces. Therefore, as has been mentioned, it is possible today to
unambiguously encode an SL name as (firstname + "." + lastname) or
(firstname + " " + lastname).

(2) As mentioned at
https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead
and
at
https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up
Linden
is investigating modifications to "names" in SL. However, it is too early to
comment on any details at this time.

(3) That said, the investigative work for (2) is being done with the
benefits of (1) held firmly in mind. (As with practically anything in the
biz, this statement is not a contract or guarantee.)

Therefore, from Linden's perspective, we can live with the proposed
simplified requirements of a single string. If it becomes necessary to
revisit that in the future we'll raise it.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 09:02:10 -0700

okay. removing the two name option from the draft.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Tue, Apr 6, 2010 at 8:51 AM, Joshua Bell <[email-masked]> wrote:
> (2) As mentioned
> at https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead and
> at https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up Linden

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 20:16:33 +0200

> okay. removing the two name option from the draft.

There is no need to remove the notion of "agentID" versus
"accountID" I think. Both are thus different that I can
imagine there is the need for an overlap period, or else
indeed very specific encoding would be needed(?) for the
one-string.

[ Perhaps it should be noted however that in theory it
is possible to use the one string as a custom xml message
in itself (like Dzontas example).

This would fall completely outside the realm of VWRAP,
but it does raise the question of there really is a need
for two different types of login strings in VWRAP therefore.

The string, as defined in VWRAP, could contain (as defined by
whoever the provider is) for example:

<type>agentID</type>
<first>Firstname</first>
<last>Lastname</last>,

or

<type>accountID</type>
<ID>[email-masked]</ID>

or any encoding a provider wishes.]

I am assuming you mean that in the draft agentID will be
a single string, just like accountID?

---

From: Morgaine <[email-masked]>
Date: Wed, 7 Apr 2010 06:29:26 +0100

Thanks for confirming that, Joshua!

The nature of the agent field is a small thing, but progress has been made.
:-)

Morgaine.

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

On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell <[email-masked]> wrote:

> Speaking for Linden:
>
> (1) For the purposes of VWRAP interop, it is acceptable to us to assume
> that a human readable agent identifier ("name") for Second Life can be
> coerced to and from a single string field. Today, SL firstname/lastname
> pairs are constrained to a subset of ASCII that disallows characters such as
> periods and spaces. Therefore, as has been mentioned, it is possible today
> to unambiguously encode an SL name as (firstname + "." + lastname) or
> https://blogs.secondlife.com/community/features/blog/2010/01/03/happy-new-year-looking-backlooking-ahead and
> at
> https://blogs.secondlife.com/community/features/blog/2010/01/22/will-the-real-you-please-stand-up Linden

---

From: Tammy Nowotny <[email-masked]>
Date: Wed, 07 Apr 2010 06:10:17 -0400

Names are a small thing but they are immensely complicated (and important.)

Morgaine wrote:
> The nature of the agent field is a small thing, but progress has been 
> made. :-)
>
>
> Morgaine.
>
>
>
>
>
> On Tue, Apr 6, 2010 at 4:51 PM, Joshua Bell <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Speaking for Linden:
>
>     (1) For the purposes of VWRAP interop, it is acceptable to us to
>     assume that a human readable agent identifier ("name") for Second
>     Life can be coerced to and from a single string field. Today, SL
>     firstname/lastname pairs are constrained to a subset of ASCII that
>     disallows characters such as periods and spaces. Therefore, as has
>     been mentioned, it is possible today to unambiguously encode an SL
>     name as (firstname + "." + lastname) or (firstname + " " + lastname).
>
>     (2) As mentioned
>     is investigating modifications to "names" in SL. However, it is
>     too early to comment on any details at this time. 
>
>     (3) That said, the investigative work for (2) is being done with
>     the benefits of (1) held firmly in mind. (As with practically
>     anything in the biz, this statement is not a contract or guarantee.)
>
>     Therefore, from Linden's perspective, we can live with the
>     proposed simplified requirements of a single string. If it becomes
>     necessary to revisit that in the future we'll raise it.
>
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>