Re: Poll remove exact address code? (was: Re: Obsolete features)
On 2006-05-22, William Yardley <mutt-users@xxxxxxxxxxxxxxxxx> wrote:
> On Mon, May 22, 2006 at 11:46:24AM +0200, Alain Bench wrote:
> > > * On Sat, May 20, 2006 Rocco Rutte (pdmef@xxxxxxx) muttered:
>
> > >> as for exact address, I'm wondering if there're people out there
> > >> which actually use it (as it's non-default).
> >
> > I know of 2 guys using +EXACT_ADDRESS, but after discussion it
> > appears that it's not for any serious nor good reason. I may seem to
> > guess that it's not far from the false assumption that "exact" is better
> > than "not exact"... Where we see wording importance. Or a (weak)
> > preference for the deprecated "address (name)" syntax. IMHO the feature
> > can be safely dropped.
>
> I used to use it because I prefer the "address (name)" syntax.
> It worked for a while, even when the release notes stated that the
> feature was broken. At some point, though, it stopped working, so I
> (reluctantly) stopped using it.
>
> Given mutt's general "you can do whatever you want even if we think it's
> dumb" philosophy, I'd much rather see the feature fixed than taken
> out... but I agree it should be one or the other, and I'm not able to
> fix it myself, so....
>
> Just out of curiosity, where in RFC(2)822 (or elswewhere) is the address
> (name) syntax listed as deprecated? A comment in paranenthesis appears
> to be syntactically correct, if I'm reading them right.
RFC 2822, section 3.4. Address Specification, page 16:
Note: Some legacy implementations used the simple form where the
addr-spec appears without the angle brackets, but included the name
of the recipient in parentheses as a comment following the addr-spec.
Since the meaning of the information in a comment is unspecified,
implementations SHOULD use the full name-addr form of the mailbox,
instead of the legacy form, to specify the display name associated
with a mailbox. Also, because some legacy implementations interpret
the comment, comments generally SHOULD NOT be used in address fields
to avoid confusing such implementations.
Section 1.2.1. Requirements notation, page 4:
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119].
RFC 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA