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

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Oct 2014 09:06:56 +0200

Hi there.

I was reviewing the namespace registration and have one question.

The draft says

"The changes introduced in this memo do not alter the protocol and 
retain backward compatibility with older LFB models."

If this is the case, why is a new XML namespace even desirable?

(Other than that, I'm sort of ok with the registration, but it strikes 
me that assigning a new namespace is a very bad idea).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Oct 2014 09:33:27 +0200

> me that assigning a new namespace is a very bad idea).

Thinking about that some more: if a new XML namespace is used, the 
format definitively is *not* backwards compatible anymore (every piece 
of software that understood the old format will have to be rewritten).

Best regards, Julian

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 22 Oct 2014 15:54:46 +0300

Greetings Julian,

I'm a little confused on why you think there is no backwards compatibility.

LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace.
LFB definitions that use the 1.1 namespace are not always valid with the 1.0
namespace.

That means that a software that understands LFBs in the 1.1 namespace can,
without any change, understand older LFBs. That was the end goal.
Software that understand the 1.0 namespace (even if we didn't change the
namespace) will, of course, have trouble parsing the new xml if the
extensions are used.

This document did not change any LFB definitions developed with the 1.0
namespace. As there was no reason for that as 1.1 is backwards compatible
with 1.0
The namespace is a way to distinguish the different versions and notify that
in the 1.1 namespace these extensions apply.

Thus, I don't understand why old software will be needed to change in order
to understand the old format. 
For the new format, of course you'll have to change it. But for the new
format you'd definitely had to update the software if you want to be
compatible with the 1.1 namespace, so I don't see the issue.

Is something I miss?

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: forces [mailto:[email-masked]] On Behalf Of Julian
> Reschke
> Sent: Wednesday, October 22, 2014 10:33 AM
> To: [email-masked]; [email-masked]
> Cc: Amanda Baber; Graham Klyne
> Subject: Re: [forces] draft-ietf-forces-model-extension
> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Oct 2014 15:10:24 +0200

> LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace.

Unless I'm missing something: no, they are not.

Can you provide a 1.0 example, and show how it is valid according to the 
1.1 schema?

> LFB definitions that use the 1.1 namespace are not always valid with the 1.0

They are never, because they use elements from a different namespace.

> without any change, understand older LFBs. That was the end goal.

No. Unless I'm missing something it'll have to support both namespaces, 
thus both schemas.

> namespace) will, of course, have trouble parsing the new xml if the

...well, unless you have a sane extensibility model to start with.

> in the 1.1 namespace these extensions apply.

Changing the XML namespace name essentially means you have a new 
vocabulary. No existing code (unless it was buggy enough to ignore 
namespace declarations) will recognize elements from the new namespace.

> compatible with the 1.1 namespace, so I don't see the issue.

At least one of us does :-)

Best regards, Julian

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 23 Oct 2014 07:51:05 -0400

On Wed, Oct 22, 2014 at 9:10 AM, Julian Reschke <[email-masked]> wrote:
> Can you provide a 1.0 example, and show how it is valid according to the 1.1
> schema?
>

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.

I can see a challenge with toolkits that look at the new namespace vs old.
Old toolkits wont be able to understand the semantics of the new namespace.
New toolkits should be able to understand the semantics of both old and
new extensions - if the author chooses to. If i understood Evangelos
correctly: He is saying the content inside the new namespace is basically
backward compatible. If i understood you correctly, you are saying the
moment you say it is version 1.1 you cant talk about the content inside
and compare it with 1.0.
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?
How does one detect there's new extensions?

cheers,
jamal

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Oct 2014 14:42:34 +0200

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

> Old toolkits wont be able to understand the semantics of the new namespace.

Right. So this is *not* backwards compatible. A message using the 1.1 
namespace will not be processable by a recipient that expects the 1.0 
namespace.

> moment you say it is version 1.1 you cant talk about the content inside

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

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

> How does one detect there's new extensions?

By inspecting the element name and see whether it's known?

Best regards, Julian

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 23 Oct 2014 09:31:23 -0400

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

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

> 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

---

From: Joel <[email-masked]>
Date: Thu, 23 Oct 2014 10:04:52 -0400

The XML in the draft is NOT carried over the wire.  It is a definition 
of structures which is referenced by the protocol carried over the wire.

Yours,
Joel

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 27 Oct 2014 21:59:31 +0200

Greetings Julian,

Apologies for the late reply.

As Jamal and Joel both noted, the model does not affect the protocol at all.

The change of the namespace was suggested by Adrian during his AD review
(https://www.ietf.org/mail-archive/web/forces/current/msg04837.html) which I
agreed to. I am more comfortable with keeping the new namespace as that will
clearly specify that extensions are expected.

Now, how about if we added the following text in the document. Would that
address your concerns?
	
"The extensions described in this document, are backwards compatible in
terms of the operation of the ForCES protocol.  In terms of the XML, any
definitions that were valid under the old name space are valid under the new
namespace.  It is to be noted that any auxiliary tools that are processing
xml definitions written under both namespaces will need to be able to
understand both."

Regards,
Evangelos Haleplidis.

> From: forces [mailto:[email-masked]] On Behalf Of Joel
> Sent: Thursday, October 23, 2014 5:05 PM
> To: Julian Reschke; Jamal Hadi Salim
> Cc: Amanda Baber; [email-masked]; Graham Klyne; draft-ietf-forces-
> [email-masked]
> >>> Can you provide a 1.0 example, and show how it is valid according
> to
> >>> the 1.1 schema?
> >>>
> >>
> >> I can see a challenge with toolkits that look at the new namespace
> vs
> >> old.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 21:05:19 +0100

> xml definitions written under both namespaces will need to be able to

Hi,

that's indeed an improvement. Go ahead!

Best regards, Julian

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 30 Oct 2014 00:12:43 +0200

Greetings Julian,

Thanks for agreeing with the text. The text was actually a suggestion by
Joel.
So, just a quick question. I guess that I shouldn't update the draft as it
is after RFC editor editing and into IANA hands.
In order to move forward with the document, do you mind if I add the text at
the AUTH48 state? Or should I ping the RFC editor (or the one holding the
pen right now) to add it? 

Regards,
Evangelos.

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Monday, October 27, 2014 10:05 PM
> To: Haleplidis Evangelos; 'Joel'; 'Jamal Hadi Salim'
> Cc: 'Amanda Baber'; [email-masked]; 'Graham Klyne'; draft-ietf-forces-
> > (https://www.ietf.org/mail-archive/web/forces/current/msg04837.html)
> > which I agreed to. I am more comfortable with keeping the new
> > namespace as that will clearly specify that extensions are expected.
> >
> > Now, how about if we added the following text in the document. Would
> > that address your concerns?
> >
> > "The extensions described in this document, are backwards compatible
> > in terms of the operation of the ForCES protocol.  In terms of the
> > XML, any definitions that were valid under the old name space are
> > valid under the new namespace.  It is to be noted that any auxiliary
> > tools that are processing xml definitions written under both
> > namespaces will need to be able to understand both."
> >
> > Regards,
> > Evangelos Haleplidis.
> 
> Hi,
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Oct 2014 23:29:51 +0100

> pen right now) to add it?

Adding it in AUTH48 is fine, as long as your AD and the WG are in the loop.

Best regards, Julian

---

From: Evangelos Haleplidis <[email-masked]>
Date: Thu, 30 Oct 2014 13:59:30 +0200

Greetings Julian,

Great, thanks! I'll add it at the AUTH48 and cc the wg and Adrian.

Regards,
Evangelos Haleplidis