Subject: [ogpx] Notes from my parts of the VWRAP session

From: Mark Lentczner <[email-masked]>
Date: Wed, 24 Mar 2010 09:12:28 -0700

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

[email-masked]

Zero Linden
[email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 24 Mar 2010 11:28:11 -0700

Mark Lentczner wrote:
> **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.

Just to clarify from IETF session chat to make sure we are on the same page:

This is an acceptable standard query: /Resource/Path/<uuid>

This is not standard, but an acceptable customization: 
/Resource/Path/<uuid>?encode=text&format=json

We shouldn't expect the customization to be supported across the board 
on all implementations. Instead, from feedback and various reads, we 
should make use of the Content-Type: field where possible instead of 
path arguments.

For example: Content-Type: text/json

Or: Content-Type: application/xml+llsd

Other operation arguments are probably best found in the body of the 
query rather than the header.

Please clarify further is this what was not intended.

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 30 Mar 2010 12:45:55 -0600

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

Mark, can you point me at the LLIDL handling code? I'm interested in LLIDL's application to unit testing.

John