In <p06250108c2d3f6265dd0(_at_)[172(_dot_)28(_dot_)170(_dot_)243]> Pete Resnick
<presnick(_at_)qualcomm(_dot_)com> writes:
On 7/30/07 at 11:32 AM +0000, Charles Lindsey wrote:
It would probably be helpful for a start to state clearly that what
is actually written in a domain literal (whether in an address or a
mesg-id) MUST/SHOULD agree with the specification of some widely
recognized numbering/routeing scheme (which, at the moment means IP4
or IP6 of course).
Why can't that be done in the documents which define where these
things get used, thereby limiting dependencies.
I think you misunderstand what I was saying. Sure some document (e.g. RFC
2821, but there may be more in the future) will say that, for its
purposes, domain literals are limited to such and such (likely described
by ABNF).
What I am suggesting for RFC 2822bis is that it should state clearly that
domain literals SHOULD (maybe even MUST) NOT be used unless there exists
some identifiable document which allows that particular domain literal.
However, suppose some future addressing scheme _does_ admit quoted-pairs
First off, let's note that it is not the addressing scheme that
admits quoted pairs; it is the representation of those addresses in a
message. Things that interpret those addresses parse out the quoted
pairs (and square brackets and the CFWS for that matter) to get the
address.
Sure. If we allow '\' in dcontent (as I suggested, but without any
connotation that it is a quoted-pair) then some new addressing protocol is
welcome to say that `\` has some special semantic meaning such as to quote
the following character - supposing that such a feature facilitates the
routeing/transport/whatever which uses that new kind of address.
But that should be totally opaque to pure mail protocols which create or
handle messages (i.e. they have no business "improving" things by
substituting 'q' when they see '\q'). If and when such a messages comes to
be tranported by the new protocol using the new address format, then sure
that protocol can choose to regard '\q' and 'q' as eqivalent, if that is
how that protocol works.
That said, imagine that it makes perfect sense for a new addressing
scheme decides to use a special other than "." in a domain literal,
and it further turns out that parsers do bad jobs if those characters
are not quoted. We might want to encourage the use of quoted pairs in
those cases.
As I said, that is an internal matter to be specified by and for the new
addressing scheme.
And again, I can't get all that excited (without some real examples)
about implementations that can't go through a text string and unquote
quoted pairs.
I think, as Russ has explained, that just about every existing Netnews
relaying agent would not be able to do that.
Imagine a news server that is offered 100,000 articles a day, and that
keeps a History file of two million or so articles that it knows about,
and it has to discover, for each of those 100,000 articles, whether its
<msg-id> is already recorded in its History file.
No implementor can afford to examine each incoming <msg-id> for special
cases such as quoted-pairs that in practice are virtually never seen. The
most he can afford to do is to read the incoming stream until he finds a
'>', and that is then the msg-id he is going to use.
There undoubtedly exists software within Netnews that will break if
this SP is absent...
... since it is the invariable practice within email MUAs to include
this SP, putting such a MUST in email would incur no problems...
[and later]
There undoubtedly exists Netnews software which will break without
that whitespace...
Yes there are undoubtedly news implementation that would break in
that situation...
Undoubtedly? Invariable? Use of these words *increase* rather than
decrease my suspicion, and therefore my desire to leave things
exactly as they are now.
Yes, the USEFOR WG discussed these cases (but not extensively, since the
bulk of its members had a good understanding of how Netnews worked and
were well aware of what would not work). So the necessity for that SP was
reaffirmed (several times, because newcomers regularly raised it).
When our draft was finally submitted to the IESG, one of its members
queried this particular matter, and after we had explained the reasons and
the situation, our text was accepted as it stood.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5