[vwrap] #19: handling binary serialization errors

["vwrap issue tracker" <[e-mail]>]

#19: handling binary serialization errors
--------------------------------+-------------------------------------------
Reporter:  markl@…              |       Owner:  markl@…            
    Type:  enhancement          |      Status:  new                
Priority:  major                |   Milestone:                     
 Version:                       |    Severity:  -                  
Keywords:  TypeSystem           |  
--------------------------------+-------------------------------------------
 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

 From my (Mark) message about this:

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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/vwrap/trac/ticket/19>
vwrap <http://tools.ietf.org/vwrap/>