John C Klensin wrote:
(ii) either put the initialization draft on the standards
track with it or publish it as informational and use the
That's a formal point: The initial registry is too long to
put it in the IANA considerations of the main document, and
it will be soon obsolete. Therefore it had to be a separate
Because the WG wanted a proper last call also for this part
it was published as I-D. Same idea as for e.g. RfC 4021 - a
part of the header field registry defined in RfC 3864.
Apparently RfC 4021 is "standards track", but "informational"
for the initial registry is also possible. I don't get the
need for "downref" in this case, the reference to the initial
registry in the main document _is_ only informational.
Do "informational" RfCs created by a WG get a "last call" ?
I'm not sure what the last paragraph in 2026 4.2.3 means.
Something's odd with the procedures here, I'd be surprised
if RfC 4021 would be promoted on stadards track, it's only
a (now already obsolete) snapshot of a part of a registry.
The documents make reference to the "record-jar" format. I
believe the text in ltru-registry is sufficient to define
the portion of that spec that is relevant
Yes, the defined format is "inspired by" record-jar, it does
not claim to be the real thing. E.g. it doesn't have arbitrary
comment lines, OTOH it defines a way to encode Unicode by the
known &#x????; sequences for u+????.
a dependency on a moderately expensive book that could go out
of print as part of the definition for an IANA registry
No, it's also only informational for those interested in "the
real thing" instead of what's used for the registry and future
incidentally, the reference given is incomplete.
Yes, the draft author knows already how to add the proper ISBN
with xml2rfc, "easily fixed" as you said. Not referencing the
original idea at all would be wrong. But the reference in the
initial registry draft is in fact unnecessary. Think of it as
some kind of "informational credits" in the main document.
We also considered a pure 2822-like format with CRLF CRLF as a
record separator, but the WG preferred CRLF "%%" CRLF, that's
all - no copyright traps and no necessity to buy the book (e.g.
I don't have it).
Ietf mailing list