Subject: [xml2rfc] getting past the <vspace> conundrum

From: Tony Hansen <[email-masked]>
Date: Thu, 23 Oct 2014 21:01:13 -0400

I think there's a couple points that need to be brought up about <vspace>.

*) <vspace/> is being deprecated from use.

*) It is expected that NO deprecated elements will be allowed in actual 
RFC XML fils. (That's part of the definition of deprecated elements.)

*) However, in the meantime, <vspace/> will still be available for use 
in I-Ds.

I think we need some more experience with the V3 formatter to decide if 
there's anything in how <vspace/> is really being used that

*) couldn't be done in other ways, or
*) would make us rethink either that deprecation, or
*) the need to provide better facilities for such.

     Tony Hansen

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Oct 2014 13:00:39 +0200

Tony,

I had not read this when I sent my previous mail.

I think the formula - "not allowed in RFC files, but allowed in ID
files" - works for me.

Caveat - it could that some of the use cases that are not discussed
turns out that <vspace> is useful for RFC files also. But I don't
think I have enough insight to have an opinion on that.

/Loa

On 2014-10-24 03:01, Tony Hansen wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Tony Hansen <[email-masked]>
Date: Fri, 24 Oct 2014 08:36:51 -0400

One additional note: the plan for deprecated items is that they 
disappear in some future version of the grammar.

     Tony

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Oct 2014 15:54:15 +0200

Tony,

Does this mean that what is working for IDs early in the life if v3,
will cease to work towards the end of its life time.

This seems a bit ill-considered, if I write an ID where the grammar
works and then return to it some arbitrary time later it will no longer
work?

/Loa

--

---

From: Tony Hansen <[email-masked]>
Date: Fri, 24 Oct 2014 10:33:26 -0400

Hmmm, we're talking past each other a bit.

We do expect there to be some give and take on the v3 grammar while we 
work on the tools and cycle experience from the tools back into the 
grammar and vice versa. We would certainly try not to break anything in 
that process, and any breakage would be discussed prior. This is just 
like the work done in any of our working groups on protocol definitions.

When the v3 definition is DONE, some tags and attributes from v2 will be 
listed as deprecated.

Being marked as "deprecated" means a few things:

*) The deprecated tag/attribute MAY be used in I-Ds.
*) The deprecated tag/attribute will NOT be used in the files that the 
RFC editor publishes.
*) The tools may generate warnings when a deprecated tag/attribute is 
used. (When the RFC editor uses the tools, they would instead produce 
errors.)
*) A later version of grammar (version 4 or version 5, if such were ever 
to be done) would be free to remove the deprecated tag/attribute from 
the grammar and subsequent tools.

A consequence of all this is that for any I-D that makes it to the stage 
where it is going to go to the RFC editor, any deprecated tag/attribute 
will need to be converted to a non-deprecated equivalent. I'm sure that 
the RFC editor would prefer that this replacement would occur much 
earlier in the process, such as before WG last call or before an I-D 
became accepted as a WG document.

I'll send another message talking about the consequences of this with 
respect to <vspace/>.

     Tony