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

[Dave CROCKER <[e-mail]>]

On 4/5/2010 9:32 PM, Barry Leiba wrote:
> 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".

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

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



> Why not define the agent identifier in a self-parsing way?  Something
> 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