Re: [vwrap] [ogpx] type-system : guidance for binary serialization implementers

[Mark Lentczner <[e-mail]>]

To summarize, there are several possible mal-formed conditions in a binary serialized LLSD value:

1&2) The "object count" is inconsistent with the number of objects bound by the matching opening and closing tags for an array or map. (Original e-mail had these as two cases, too few and too many)
3) No matching closing tag is found for an array or map
4) Something other than a 'k' tag found where 'k' required in a map
5) A 'k' tag encountered either outside a map, or where a value is required in a map
6) Duplicate keys in a map

My reading of the intention of the Linden Lab C++ implementation is that cases 1, 2, 3, 4, and 5 result in a parse failure for the entire binary LLSD. Duplicate keys (case 6) are handled by "last one wins".

I believe that the mal-formed cases 1 through 5 should result in rejection. I can see no benefit to trying to repair what can only have been generated by incorrect code. (And yes, I lament the redundancy between the object counts and the closing tags.)

Case 6 is tricker. I'm loathe to say that duplicate keys result in rejection, since that my difficult or awkward in some implementations. That would lead me to say "if there are duplicates, the result is undefined." But then I worry that people will do things like hide values from some implementations by relying on the priority they use. Which leads me to just say "last wins", though that too might be more awkward for some implementations. Still mulling....

	- Mark




Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[e-mail]

Zero Linden
[e-mail]