--On Wednesday, 07 September, 2005 01:10 +0200 Frank Ellermann
<nobody@xxxxxxxxxxxxxxxxx> wrote:
> John C Klensin wrote:
>
>> (ii) either put the initialization draft on the standards
>> track with it or publish it as informational and use the
>> downref procedure,
>
> 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
> document.
>
> 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.
That wasn't clear from the text, but I may not have read closely
enough. See below.
> 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.
Independent of what that paragraph means, it is common for
anything that is presented by the WG to IESG for comment to get
a last call within the WG; I can't imagine a WG chair doing
otherwise. Whether WG informational documents are then Last
Called to the IETF is up to the IESG and relevant ADs. There is
no requirement that it be done, but it generally is done if the
AD concludes that the document is likely to be either
consequential or controversial.
> 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.
Personal opinion: What should be done in cases like this is to
structure the I-D so that it clearly differentiates between:
(i) The specification, rationale, and other contextual
information for the initial registry contents, and
(ii) The actual listing of the registry initialization
and that the specification provide for some way of
distinguishing between initial registry entries and subsequent
ones by examining the registry (this could be as simple as the
specification of a particular date.
Then an instruction to the RFC Editor could be included in the
I-D asking that they not publish the initialization document
until the entries have been made in the IANA registry and then
that the list of entries be dropped and replaced with a pointer
paragraph and reference. That would lead to an RFC that was
clearly informational and fairly short, saving everyone
long-term problems.
For draft-ietf-ltru-initial, that would mean retention of
sections 1, 2, and 4-7 into the RFC but the replacement of
section three with, e.g.,
"3. The initial contents of the registry as specified
in this document are those entries in the IANA registry
[IANA-registry] with a field-name of "Added" and a value
of "2005-07-10". Note that [ltru-registry, Section 3.1]
requires that an "Added" field appear in each
registration record and that its Section 3.3(1)
specifies that field must not be changed after
registration."
Then you are done. Presto, clearly informational document,
historical information retained in the registry (which is where,
IMO, it belongs), no chance of anyone ignoring the instructions
in the third paragraph of Section 1 that the initialization list
in the RFC is not the registry, and an RFC that runs around ten
pages rather than 118.
I think that would be a win all around. But, again, just my
opinion.
>> 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
> extension registries.
I would recommend that, as an editorial matter, use of phrases
like "inspired by" or "derived from" would clear up a lot of
confusion before it starts, making it clear that the book is not
needed. For example, the beginning of the second paragraph of
3.1 might read
'The registry will be in a text file format that is
fully specified below. This format was inspired by the
"record-jar" format [record-jar].'
But, again, this is purely an editorial matter as far as I'm
concerned.
>> 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).
Not a decision on which I'd ever be inclined to second-guess a
considered WG decision.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf