More Path notes (was: Protocol changes in draft-allbery-usefor-usepro-00)

[Russ Allbery <[e-mail]>]

I'm going to start trying to break this message up into separate subjects
per topic.  I'll also try to only respond to places where there seems to
be more to say or some text change that's needed.

Charles Lindsey <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:
>> Charles Lindsey <[e-mail]> writes:

>>> 1. [-1] (2.2) <path-identity> - Possibility to use a FQDN not
>>> resolvable in the DNS.

>>> (This was a suggestion by Harald, & 1 of 2 alternatives in USEPRO)

>> Intentional, but I don't object to changing it.

Actually, I didn't make this change, but both of us misread my text.  :)
This case is still allowed (it's my 2nd point).  What changed was the
wording of the 1st point.

>> The intentional change here is that I added a different preferred first
>> option, namely the FQDN of the news server itself.

> Which I did not quite understand. Did you mean the A or AAAA record? In
> which case please be explicit. But I would prefer to allow CNAMEs and
> MXes as well.

Those are both allowed by the second option.

FQDN is used without further qualification in USEFOR as well (section
3.2.8).  I think it's a technical term that readers of standards should be
expected to know and don't think it needs further elaboration.  If it
does, USEFOR also needs to be modified.  One of the reasons why I'd rather
leave it as-is is that it's one of those terms where attempting a formal
definition can quickly get off into the weeds dealing with multihomed
hosts, different DNS RRs, and so forth.  But I can see why not clearly
defining a term in a standard could be a problem, so I can be convinced we
need to say something.  (Ideally, maybe there's a definition somewhere
else we can just reference?)

>>> 2. [00] (3.2) <path-identity>s are case-sensitive.

>>> I was always told that some servers treated them one way and some the
>>> other, so you could not rely on either. If anything, I would have
>>> expected case-insensitive (that is what domain-names are, and what
>>> USEFOR declares <diag-keyword>s are).

>> Intentional change.

>> Declaring them case-sensitive is the conservative choice.  If you treat
>> them as case-sensitive and they're actually compared
>> case-insensitively, everything works fine.  The opposite is not true;
>> if your Path identity varies in case, servers that compare
>> case-sensitively may add incorrect MISMATCH entries or send you
>> articles that you sent them.

> OK, I will buy that.

The more I research this, though, the more I think that while the above is
true, it's not ideal.  Poking around a bit, it looks like a *lot* of
existing implementations are case-insensitive, and I'm not sure I want to
declare that incorrect.  Accordingly, I now have the following text, which
I think is an improvement.  Please, everyone, let me know if you disagree:

   Some existing implementations treat <path-identity> as case-
   sensitive, some case-insensitive.  The <path-identity> therefore
   SHOULD be all lowercase and implementations SHOULD compare identities
   case-insensitively.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>