Re: Re: Last erratum last call

On Mon, 7 Apr 2008, Frank Ellermann wrote:
> Stuart D. Gathman wrote:
>
> > You had me convinced that PermError was better than nomatch.
>
> LOL, for the old 3:2 "rough" consensus I could claim that it
> was actually 4:1 pretending that I changed my mind, now we
> could be back at 2:3 ;-)

I know I voted for PermError, but I assumed I was in the minority.  I
agree with the below.

> > literally putting a:example..com is a plausible typo that
> > should get a PermError
>
> Yes.  And dynamically getting example..com as a <target-name>
> is also not what section 4.8 wants:  A fully qualified domain
> name with a series of labels separated by dots.  There is no
> DNS-syntactically valid FQDN with an empty label.  Ignoring
> empty label for the root here - nobody adds a dot at the end
> of <target-name> if it is already there, permitted in AUTH48.
>
> For include:example..com the outcome is a PermError.  That is
> consistent for check_host() results PermError or "no match",
> both are mapped to PermError.
>
> For "a" and "mx" an invalid <target-name> is arguably unclear.
>
> Unfortunately "ptr" explicitly specifies "no match" for DNS
> errors, and if ptr:example..com queries work in some way the
> result can only be an error.
>
> Yesterday I found a dig for W2K, it says that example..com is
> not a legal name.  W2K nslookup reports an unspecified error,
> with -d it admits that res_mkquery() didn't work.  JFTR, it's
> of course not different from what I got on OS/2 a year ago.
>
> The "last erratum" could admit what Julian said, RFC 4408 is
> very unclear wrt this issue, and implementations could handle
> it differently, but please not as TempError.
>
> > I was considering posting an auto-note to postmaster in case
> > of PermError in addition to a DSN, but PermError from macros
> > would discourage that.
>
> Point.  For the erratum, if we allow both outcomes, I could
> add a caveat that implementations should state how they handle
> invalid <target-name>.  They could even offer to configure the
> desired behaviour.
>
> For the test suite allowing both is simple.  But insisting on
> "whatever you do be consistent" in the test suite is something
> it can't do, or can it ?
>
>  Frank
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: http://www.listbox.com/member/archive/1007/=now
> RSS Feed: http://www.listbox.com/member/archive/rss/1007/
> Powered by Listbox: http://www.listbox.com
>

--
Boyd Gerber <[email protected]>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047