On Thu, 18 Sep 2008 10:07:12 -0700 (PDT) The IESG wrote:
The IESG has received the attached text for a proposed IESG Statement:
IESG Statement on the Usage of Assignable Codepoints in Specification
Examples
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this proposed IESG statement. Please send substantive
comments to the ietf(_at_)ietf(_dot_)org mailing lists by 2008-10-02.
Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case,
please
retain the beginning of the Subject line to allow automated sorting.
On behalf of the IESG,
Russ Housley
= = = = = = Text of Proposed IESG Statement = = = = = = =
Hi,
My comment isn't similar to the rest of the mail threads here:
I find the use of the word "codepoint" confusing here. It apparently means
something different to some readers (or writers) here. To me (and I'm almost
never unique in things like this), it means a point in a character set
space. See http://en.wikipedia.org/wiki/Codepoint or possibly
http://code.google.com/search/#q=codepoint .
Maybe here it means an extension of that, like "a (virtual) point in some
world network address space." Is that close?
Perhaps it should define what a codepoint is or use some other word/phrase
for it.
IESG Statement on the Usage of Assignable Codepoints in Specification
Examples
Protocol specifications and other documents intended for RFC publication
often include useful examples with correctly formatted and syntactically
valid codepoints. Example codepoints may be names, addresses or assigned
numbers, such as email addresses, domain names, IP addresses or ports. The
value used in an example may already have been assigned or may become
assigned in the future to entities on the Internet, and this can cause
problems.
Codepoints used in specification examples can result (and have in the
past resulted) in some amount of unwanted traffic. The impact of this
unwanted traffic varies highly depending on the context and nature of the
example. Some examples of causing unwanted traffic include:
1) Spam: apparently valid email addresses in an RFC are widely believed
to have been harvested and included in Spam lists. The domain may receive
spam at mailboxes other than the one used in the example email address, if
the domain name is used in common name or brute force attacks.
2) Test code: when test implementors use the examples from the
specification, sometimes they forget to change the example addresses,
potentially resulting in unwanted traffic to the example address.
3) Configuration files: example configuration files are commonly copied
and then edited. Configuration files may be distributed to a large number
of hosts as part of a software package. That software may be deployed or
tested before removing the example address. In several cases, this class
of error caused substantial impact on the resource named. The results were
effectively distributed denial of service attacks and increased
operational costs for the targets.
Use of examples in RFCs is not a new concern. The issues have been known
and considered for several types of codepoints. BCP 32 (RFC 2606 -
Reserved Top Level DNS Names) reserved some domain names for use in
examples. RFC 3330 (Special-Use IPv4 Addresses) and RFC 5156 (Special-Use
IPv6 Addresses) assigned some IP address ranges specially for examples and
documentation. RFC4735 (Example Media Types for Use in Documentation)
registered one example media type and one subtype under each of the
registered media types for example use. Other similar specifications and
reserved codepoints exist.
The IESG understands that not all types of codepoints have reserved
values or ranges for documentation and examples. The IESG also understands
that sometimes the use of reserved values makes examples harder to read or
less apt. In these cases authors have several options:
- The specification itself can request further values or codepoints to
be assigned.
- The author can get permission from the holders of assigned values.
However, the stability of the assignment needs to be considered.
- The author can request approval for use of non-example addresses,
names or codepoints, with an analysis of the expected effect of this use.
Documents that update previously published RFCs fall under less pressure
to update examples that have already been published. The use of reserved
codepoints is still recommended in these documents when new examples are
added or when examples change.
Upon publication of this statement, the IESG will apply the following
requirements to documents submitted for publication as RFCs in the IETF
Stream. The document SHOULD use values reserved for examples where such
assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156) and when
the necessary semantic can be communicated clearly enough. If unassigned
codepoints are desired it is RECOMMENDED that those codepoints be assigned
or registered. If assigned codepoints are desired, it is RECOMMENDED that
the authors get approval from the current codepoint holder. Designers of
new protocols SHOULD consider example usage and register or assign values
for example usage.
Regards,
---
~Randy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf