Re: [vwrap] Parsing of invalid LLSD elements in XML

[Carlo Wood <[e-mail]>]

I vote for 1). There is no way the receive can start to guess what
the message means in this case, and therefore the whole thing
should be escalated immediately, so whatever is wrong can be fixed.

On Wed, Mar 31, 2010 at 02:53:25PM -0700, Joshua Bell wrote:
> Mark Lentczner and I were discussing this issue earlier today offline, and I
> wanted to recap it to the list.
> 
> draft-hamrick-vwrap-type-system-00 does not define what should happen when
> trying to parse this LLSD XML fragment (pretend it has the right prologue and
> hence is well-formed XML):
> 
> <llsd>
>     <map>
>         <key>test</key>
>         <uuid>this is not a uuid</uuid>
>     </map>
> </llsd>
> 
> There are at least three reasonable outcomes:
> (1) Reject the payload entirely - the entire message should be rejected
> (2) Produces a map; value associated with key "test" is a UUID of
> 00000000-0000-0000-0000-000000000000 - which would be the result of converting
> the string "this is not a uuid" to a UUID
> (3) Produces a map; value associated with key "test" is the Undefined value
> 
> (The map is, strictly speaking unnecessary, to the example, but it clarifies
> the context in which #3 occurs)
> 
> This is not confined to UUIDs; similar issues occur with Date and Binary types
> in the XML serialization. The JSON serialization appears  "immune" to this spec
> ambiguity because primitive types always end up as Boolean/String/Real/
> Undefined (in LLSD parlance); conversion to Integer/UUID/Date/URI/Binary can
> only occur at the application level. The Binary serialization appears "immune"
> to the spec ambiguity as well (possibly edge cases if a NaN or Infinity was
> used for a Date?)
> 
> Thoughts?
> 

> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap


-- 
Carlo Wood <[e-mail]>