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

["Robert G. Jakabosky" <[e-mail]>]

On Sunday 28, Meadhbh Hamrick wrote:
> 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."

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?

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

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?

> 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/ * [e-mail]
> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx



-- 
Robert G. Jakabosky