[rfc-i] Review of v3 vocabulary

[julian.reschke at gmx.de (Julian Reschke)]

(I still haven't read Paul's spec back-to-back, but I scanned this 
feedback to see what applies to v2 as well...)

On 2014-11-05 06:41, ietf at augustcellars.com wrote:
> Paul,  I apologize for this being so disjointed.  I am doing it on a
> surface as my laptop is n the shop and I have not figured out how to do
> things correct yet.  Also I reviewed in terms of grammar rather than
> linear.  Hope it is not too disjoint or incoherent.
>
>
> jim
>
>
>
> Section 2.31 if only one allowed,the draft processor might remove the
> <link> element ?

What do you mean by "if only one allowed"?

That being said; I think this section should reference Web Linking (RFC 
5988), and in particular should stick with the rel vocabulary related to it.

> Section 2.31.2what does an empty rel attribute mean.
>
> Is there a required warning for unknown rel values?

It's a candidate for a warning, but do we require warnings anywhere?

> 2.45.4is ipr required for all drafts?Any other documents?

It's not required by the vocabulary. It might be required to be able to 
submit an I-D or RFC.

> A.2.1.2does the word default imply a processor action?

Context? I don't see "default" here.

> A.2.1.3 is this incompatible independentrfcs?

I believe so.

(Note that this whole appendix is a copy from draft-reschke-xml2rfc, 
which is due to be published as RFC soon).

> Section 2.45.7 why a single section? Section 2.45.7isthis numbers or
> strings rfc XXXX for rfcs?

"Single section"? No context.

"A comma-separated list of RFC numbers or Internet-Draft names."

> What about obsolete="draft-foo-03" for -04?

It doesn't obsolete it in the sense of the RFC standards process.

> Section 2.45.8 - is this based on the category attribute?Is there
> additional notation if the document is part of a series (i.e. of 3
> documents)

Yes and no.

> Section 2.45.9 - default - "yes"?

I agree that would be a better default.

> Section 2,45,14 can have both updates and obsoletes?

Yes.

> Section 2.60how do abbrev and ascii interactis there an ascii only
> requirement on abbrev?

I don't see why we need an ASCII equivalent here at all.

> ...
> 2.46.6what does the value include mean?Include even if past tocDepth?

We should test what current processors do.

> 2.46is name optional?If not sections cannot be emptyif so would title be
> required?

The grammar currently makes <name> required, but that is a bug (as it 
breaks v2 documents).

> I don?t understand artwork
>
> 2.11.2If I quote a private email or an unpublished document, what do I
> put here?I don't understand how this can be required.

It can't be.

> ...
> 2.35.4what is the bullets here doing?Bullets are ul as well

?

> 2.63do I get control on bullet characters?

You don't right now.

> 2.58 - td is missing the open angle bracket
>
> 2.54 - why are more than one tbody is allowed?

That looks like a bug to me.

> 2.43 - does displayreference change the sort order?

It should.

> 2.43 - how do I do <references title=references><references
> title=normative/> or is that no longer allowed?

It's there, isn't it?

    In the early days of the RFC series, there was only one "References"
    section per RFC.  This convention was later changed to group
    references into two sets, "Normative" and "Informative" as described
    in [RFC7322]).  This vocabulary supports the split with the <name>
    child element.  In general, the title should be either "Normative
    References" or "Informative References".

(BTW: <name> needs to be optional here as well)

> 2.43 - I want reference elements to be optional in the references
> section. I often put in the structure without yet filling any references
> until I need one
>
> 2.43 - what about referencegroup as an element?

It seems it's currently unused in the grammar (does not appear as child 
element anywhere).

> ...
> Section 2. - I am having a number of different problems with the artwork
> textI don't know if this is because it is not clear, or I am being more
> ornery than usual.
>
> The text appears to imply that bitmaps are reasonable artwork.I thought
> that it was going to be restricted to ascii art and svg at this
> time.(Yes I realize that one can put a bitmap into an svg object.)it
> might be better to remove some of the "such as a bitmap" type text.

It's allowed in V2, and V3 is supposed to be backwards compatible.

> s/there are four was to include SVG/there are four ways to include
> external artwork/
>
> Section 2.5.2 - I don't understand why the alt attribute does different
> things based on the src attribute.I can understand it doing different
> things based on the type attribute - that is for svg it can look for
> description in the text.However if I do src="foo.txt" then it does not
> make sense for the program to try and find alt text in that file

It also doesn't make sense when src references a bitmap image, for instance.

> ...
> Section 2.25 - I would like to register a protest at the deprecation
> preamble and postamble from table and figure.The only reason why the
> kludge suggested works is the fact that there is currently no support
> expected for the concept of floating tables and figures.If these ever
> came into existence, then the fact that these do not exist means that
> the attachment of this text to the figure/table would be lost.
> ...

preamble and postamble are also useful to indicate that a piece of text 
belongs to artwork or a table, with respect to page breaking algorithms.

> Section 2.35is the style attribute mandatory?It only says it can't be
> emptyif not, is there a default

It doesn't say "mandatory" so it is not.

> ...


Best regards, Julian