Re: Last Call issues on USEPRO

Harald Tveit Alvestrand <[email protected]> writes:

> *#1582** USEPRO LC 4.3 / 5.2.3: 4.3 overlooks chkscope

Resolved but not yet published, as mentioned in the other message.

> **#1583** USEPRO LC 5.2.3: Checkgroups control messages

There are several individual questions here.

One is handling of subhierarchies in combination with groups with the same
name as the hierarchy.  I generally agree with Charles here that there
isn't a better way of handling the edge case than what we currently have,
and the group at the top of the sub-hierarchy will have to be listed in
the parent checkgroups.

Another is the serial number.  I think there are two viable options here:
unlimited-length serial numbers (the current text) or sequence-space
arithmetic.  I lean mildly towards the current text just because I don't
want to have to write the text for sequence-space arithmetic, and I find
persuasive the argument that unlimited-length numbers can be checked with
ASCII comparison and don't need to be treated as numbers.

Another is what should be done with a checkgroups that doesn't have a
serial number when checkgroups for that hierarchy previously did have a
serial number.  I think this is a gap in the current specification.

The last is whether there's a means to reset the serial number.  Currently
there isn't.

It may be worth splitting this point into four issues; the first and the
last may already be resolved, depending on whether anyone wants to
advocate doing something different about them than what we have now.

> I also have a couple of USEPRO issues in the tracker that don't seem to
> have been formally closed (another error by the chair, sorry 'bout
> that):

> 1412    USEPRO 5.3: Cancel newsgroups: matching

I remain opposed to this change.  I think we need a consensus ruling from
a chair on it.  I don't believe that it has consensus, but I'm biased by
being opposed, so I shouldn't judge that.

> 1413    USEPRO 5.5: ihave/sendme syntax

This is resolved.

> 1414    USEPRO 3.2.1: delimiter for multiple Path identities

This is resolved.  The first text option in that ticket is in the current
draft.

> 1415    USEPRO 3.2.1 - Number of path entries per site

Still open.  I think this needs a consensus ruling.  I don't believe the
proposed change is necessary, since for the purposes of the protocol
multiple systems within an ISP can be considered as one news server and
what happens internally is a black box.

> 1417    USEPRO 3.4: Injecting-agent modification of message-ID

This is resolved with the text mentioned in the ticket.

> 1479    USEPRO: Whether moderators SHOULD retain message-ID

Currently, we say:

            <t>Moderators are encouraged to retain the Message-ID header
            field if it is valid, and also retain the Date header field
            unless it appears to be stale (72 hours or more in the past)
            for reasons understood by the moderator (such as delays in the
            moderation process) in which case they MAY substitute the
            current date.  Any Injection-Date, Injection-Info, or Xref
            header fields already present MUST be removed.</t>

The question is whether the encouragement should be normative.  This is
still open.

> 1482    USEPRO 3.2: Possibility to use non-resolvable domain name as
> path-identity

This is currently permitted by:

            <t>A fully-qualified domain name (FQDN) within a domain
            affiliated with the administrators of the agent and guaranteed
            to be unique by the administrators of that domain.  For
            example, the uniqueness of server.example.org could be
            guaranteed by the administrator of example.org even if there
            is no DNS record for server.example.org itself.</t>

The proposal is to say that this is a SHOULD NOT in at least some cases
(the specific case cited is using foo.com when only news.foo.com exists in
DNS).  Currently, we only say that it's not preferred.  This is still
open.

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