Subject: [ogpx] type-system : version tag and handling unknown tags

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 28 Mar 2010 10:33:54 -0700

at least one person has commented privately about the need to add a
version tag to the binary serialization. i was initially resistant,
but now think it makes sense. the use case is we may want to have
future versions of the binary serialization with new tags.

so i propose we add this verbage to section 4.3 of the type system draft:

"version - this optional tag MUST be the first tag in a serialization
stream. it identifies the an optional version identifier, to be used
for future extension of the binary serialization. the version tag is
the lower case 'v' octet and is followed by a 32 bit value
representing the version."

related to the version tag is the idea of what to do with tags you
don't understand. many tools that process XML have a "ignore but
preserve" semantic that i think works quite well. our situation is
mildly complicated as we don't have a way to know the length of each
tag content defined in the future. ergo, i suggest we say that all
future tags consist of a tag octet followed by a 32 bit network order
unsigned integer representing the length of the tag contents in
octets. that way, if someone has inserted an experimental tag you
don't understand into a binary encoding, you can at least skip over
it.

so i also propose we add the following verbiage to section 4.3 of the
type system draft:

"implementers MAY choose to include experimental or private tags in a
binary serialization. implementations that receive tags they cannot
handle MUST preserve the tag in the serialization. to facilitate
processing of binary serializations with unknown tags, tags not
defined in this specification MUST be of the form: a single tag octet,
a 32 bit network order unsigned integer representing the length of the
tag's content, and the content."

-cheers
-meadhbh

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Sun, 28 Mar 2010 21:29:21 -0800

> representing the version."

What would old implementations be required to do, when they receive a 
new/different version?  The only use a version tag like this would provide, 
is to mark a new incompatible binary formats.  In that case, why not just add 
the version to the MIME type "application/llsd+binary+v2".

If a version is included in the spec, then it will need to have rules on how 
to handle new versions.  Will there be a way for older implementations to ask 
the sender of a LLSD message to downgrade?

> don't understand into a binary encoding, you can at least skip over

XML tools may support ignoring unknown tags, but JSON doesn't have that type 
of flexibility atleast not with how LLSD types map to JSON types.

I don't really like the idea of supporting experimental/extended/private tags.  
Since some companies will create proprietary extentions and cause divergence 
from the spec.

Also how would these experimental tags be preserved if one needs to convert 
from the binary format to JSON/XML formats?  There is already support for 
binary values in all the formats.  Wouldn't it be better to use a binary 
value instead of an unknown tag?

> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Robert G. Jakabosky