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

[Morgaine <[e-mail]>]

On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick <[e-mail]> wrote:

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


> 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 state of the SL names database is not the primary driving force for the
design of VWRAP protocols.


Morgaine.





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

On Tue, Apr 6, 2010 at 6:01 AM, Meadhbh Hamrick <[e-mail]> wrote:

> 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.
>
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Mon, Apr 5, 2010 at 9:32 PM, Barry Leiba
> <[e-mail]> wrote:
> > On Mon, Apr 5, 2010 at 4:07 PM, Meadhbh Hamrick <[e-mail]>
> wrote:
> >> 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?
> >
> > 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
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
> >
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>