Re: [forces] draft-ietf-forces-model-extension

[Jamal Hadi Salim <[e-mail]>]

On Thu, Oct 23, 2014 at 8:42 AM, Julian Reschke <[e-mail]> wrote:
> On 2014-10-23 13:51, Jamal Hadi Salim wrote:
>>

>> I am trying to understand the issue.
>> There is no namespace version carried in the protocol. And there is no
>> changes in the protocol encoding as the result of the new namespace.
>> IOW, it does not affect anything from the protocol perspective.
>
>
> Now I'm very confused. The XML defined by the draft is not carried over the
> wire?
>

Never.
Binary encodings of what is formally described by the XML goes over the wire.
We are optimizing for high performance (think updating 1M table rows using
XML ;->).
In essence, think of it as a modelling language.

>
> You could, but it simply means that you need to write code that knows about
> both namespaces. (I understand that it's not hard to do, but it is very
> different from having nothing to do).
>

So the assumption is it is *not* hard to do.

>> All the new extensions introduced are optional. And correctly written
>> s/ware will log/ignore/bailout on extensions it doesnt support.
>> Are you suggesting we keep the version at 1.0?
>
>
> If the rule for the 1.0 namespace is to ignore unknown elements then indeed
> it doesn't make any sense to define a new namespace.
>

Need to think about it.

>> How does one detect there's new extensions?
>
>
> By inspecting the element name and see whether it's known?
>

So you suck in the XML and notice these new fields?
I guess since there is no need for "discovery" across to a controller
that may work.
Note for LFBs (the OO classes we use to describe resources), the controller
needs to ask the resource owner what versions it supports so it can address it
appropriately (since the XML doesnt go on the wire).

cheers,
jamal

> Best regards, Julian