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

[Morgaine <[e-mail]>]

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.





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

On Tue, Apr 6, 2010 at 5:32 AM, 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
>