[ogpx] Notes from my parts of the VWRAP session

[Mark Lentczner <[e-mail]>]

This is what I heard from the community during the face-to-face about the issues I brought up. Most items seemed to have general consensus and understanding, and I will amend the drafts appropriately. A few items needed group input, and those have been marked with double asterisks (**).

VWRAP Type System Issues

1) Date Range text should be re-worded, since all serialization formats support a range that goes beyond the year 2038. (I forgot, during the session, that the Binary serialization uses a double precision float of seconds since the epoch.)

2) There were no concerns with the JSON subtleties (Switch to using ECMA-262 as the normative reference, etc.)

3) There were no concerns about the defaulting of the encoding attribute for binary elements in the XML serialization. However, language about which Base64 alphabet, and allowable line-breaking, padding and non-encoding-alphabet characters should be added.

**4) The JSON serialization of binary values is in the spec as an array of integers. There was some discussion that this is undesirable, and that serialization binary values as base64 encoded strings would be preferable. JSON has no attributes, so this would act like a default conversion between binary and string values, which currently isn't supported. This may be not much of an issue in practice. I'll try to write up some examples and possible confusions.

5) The direct binding to HTTP will be removed, and the language will once again define LLIDL resources in terms of an idealized REST semantics. The binding to HTTP (which is also discussed in the Foundation document) will be make clear, but in a way that future drafts could bind those resources to other transports.

**6) There didn't appear to be clear consensus on if LLIDL needed an "event-like" resource type. These would be resources that had a body with the request, but expected nothing other than confirmation of receipt in the response.

7) I saw clear dislike for including more detailed semantics of matching LLSD payloads against LLIDL descriptions. The combination of LLIDL's shape semantics, and LLSD's defaulting and conversions was felt to be the right level of specification. Nonetheless, if anyone would like a more detailed description of how our open source LLIDL system performs matching and validation, I can give pointers to the code, or provide a write-up to the mailing list if people want. Just ask.

8) LLIDL stand alone values are currently served by the named type facility. No one had any experience to indicate more was necessary.

**9) No one had concerns or issues with the addition of query arguments to LLIDL. However, within Linden's internal LLIDL user community there has been requests for also adding path arguments. While the VWRAP design currently doesn't use either of these facilities, experience has shown that backends would like to make use of both. Implementors prefer to use one type and validation system consistently throughout if possible, and so it seems reasonable to add them here. I'm looking for experience and input on these issues before proceeding with further design.

**10) The Binary serialization provides no extension mechanism. There has been at least one request for an extension that the draft authors rejected for this round because there was no clear semantics for extending the binary serialization. One idea is to add a version block. Another is to provide clear semantics for what to do with blocks tagged by unknown tags. Proposals and discussion on these ideas are needed to determine if there is a need for these features, and if so, how they should be defined.


VWRAP Foundation Issues

1) The seed capability resource response format isn't extensible. After some discussion it seems that returning a map of maps (rather than the current map of URIs) is the best approach.

**2) It is desirable to settle the issues surrounding how to invoke resources on an entity that cannot act as the "server" end in a HTTP transaction. It was clear from the discussion, and from the other drafts, that this design needs to be tackled next. With respect to the Foundation draft, and the long-poll technique, the language there should be tightened up to make clear it is a possible way to invoke these resources, and that there are operation limitations for its general use such as "okay for text IM traffic, bad for object location updates".

3) The "capability host" should be replaced by two terms "granting host" and "proxying host", since some implementations may choose to have these be different, and it is no consequence to the other parts of the capability mechanism.

4) We need a better base URI for resource names given with a relative URI. I'll find a suitable candidate involving the phrase "vwrap".

**5) I re-raised an old issue: That Foundation current requires all implementations to support both XML and JSON encodings. This seems to me like we avoided the difficult choice by equally burdening everyone. In practice, some systems don't support multiple encodings -- and it might be difficult for some to (JavaScript running in a browser, say), it isn't clear this was the best choice. On the other hand, implementing both of these is pretty easy in most environments since XML and JSON parsers are plentiful.


	- Mark


Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[e-mail]

Zero Linden
[e-mail]