[rfc-i] Proper way to include examples with yet-to-be-assigned values?

Julian Reschke julian.reschke at gmx.de
Thu Aug 12 23:09:47 PDT 2010


On 13.08.2010 02:00, Paul Hoffman wrote:
> At 4:42 PM -0700 8/12/10, Bob Hinden wrote:
>> Paul,
>>
>> On Aug 12, 2010, at 4:13 PM, Paul Hoffman wrote:
>>
>>> At 3:34 PM -0700 8/12/10, Joe Touch wrote:
>>>> Ultimately, you would get the numbers and you would put them in during one of the edit phases, or at least you'd be responsible for checking during AUTH48 anyway.
>>>
>>> This entails making significant technical changes during AUTH48. That is unseemly, to say the least. Thus my questions about a better way to do it.
>>>
>>
>> > From a draft in 6man:
>>
>>    The IANA is requested to assign a new IPv6 Neighbor Discovery Option
>>    type for the DNSSL option defined in this document:
>>
>>                  Option Name               Type
>>                  DNSSL option              (TBD)
>>
>>
>> Usually by the time it gets to AUTH48 IANA has assigned the option value and the RFC editor has filled it in.
>>
>> These were for an existing registry.
>>
>> Or were you asking a different question?
>
> A different question. Even if I use TBDs as above, we need to put some numbers in our examples because the examples use numeric entities. This means that the examples will possibly change at some point during the RFC editing process, and likely not until AUTH48.
>
> This kind of technical change is probably acceptable in AUTH48 because it is inevitable; the basic question is how to flag it so that it stands out to the Production Center before then.
> ...

For drafts that reach the RFC Editor in XML markup, the obvious solution 
would be to augment xml2rfc's vocabulary so that these TBDs stand out 
during editing, and it can easily be checked that they are gone once the 
spec is finished.

Best regards, Julian


More information about the rfc-interest mailing list