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

From: David W Levine <[email-masked]>
Date: Thu, 1 Apr 2010 12:26:30 -0400

I *think* we are talking about a very special case here.  A badly formed 
uuid, or date, element is a funny case because it's not a default, and we 
can *tell* its badly formed. 
For the other cases, the defaulting is  fine and how we approach protocol 
jitter. But.. having defined uuid and date quite precisely a badly 
formatted uuid isn't protocol jitter, its a baddly formed uuid. (And, 
having done the exercise of defining uuid and date very tightly, we're in 
the position where we have to be very careful changing what's permitted as 
valid serializations for those
specific elements, and I'd argue we're pretty well stuck with upwards 
compatible changes, or defining a "long-uuid" if we need long ones. The 
highly bound nature of these elements imposes constraints on us.)

- David
~Zah

---

From: Mark Lentczner <[email-masked]>
Date: Thu, 1 Apr 2010 15:51:51 -0700

On Apr 1, 2010, at 9:26 AM, David W Levine wrote:
> I *think* we are talking about a very special case here.

This seems at the core to me. We are asking about cases where the serialization rules have been violated. If, for example, the uuid value was correct but the closing uuid tag misspelled "</wwid>", then XML processing would have required that the whole XML document to be rejected. Seems to me that the case of the text inside the uuid element not conforming to the UUID syntax is the same: The entire LLSD value should be rejected. 

As for error reporting, I note that even though XML processing demands that the whole document be rejected, parsers are still able to report specific and helpful error messages at the receiving side. The same should be true of LLSD processors.

	- Mark

P.S.: Small bit of XML pedantry:

On Mar 31, 2010, at 2:53 PM, Joshua Bell wrote:
> ... 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>

Actually, that is well-formed XML just as it sits. There is no requirement for an XML prolog where XML doesn't mandate one.

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Carlo Wood <[email-masked]>
Date: Sat, 3 Apr 2010 14:07:48 +0200

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>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap

-- 
Carlo Wood <[email-masked]>