Subject: Re: relay checking

From: Bruce Lilly <[email-masked]>
Date: Thu, 07 Oct 2004 11:39:02 -0400

Henry Spencer wrote:

> I'm a little reluctant to use SHOULD for any of this, because that keyword
> is generally understood to mean that the action in question is nearly
> mandatory,

No, it's understood to be a recommendation (and in fact the term
explicitly and by definition carries the same weight as the
adjective RECOMMENDED); MUST and MUST NOT are mandates (for
conforming implementations -- and there is no enforcement, so
even those terms are not terribly forceful).

> I think the right choice is either to say MAY with some accompanying words
> urging people to do it,

The term MAY is generally used for clarification where an
implementor might misinterpret some normative text as
precluding something which is in fact not intended to be
precluded.  Any other use of the term tends to be vacuous
since it is generally permitted to do anything that is not
explicitly proscribed.

> or to say SHOULD but accompany it with an escape
> hatch like "to the extent that performance requirements permit".

I don't have a problem with that, but let's make sure the
right wording is used; let's not speak of performance
requirements where performance is not the major issue.

We also ought to recognize several different instances where
different fields might be checked.  Some fields are checked
at injection time and are supposed to remain unaltered
during transport. It would probably be unreasonable to
demand routine checks of such fields at every relay
agent, and given the protocol specifications (viz. checked
once at injection time and remaining unaltered thereafter)
there is only a small point (see below) in recommending
checks. There is no reason to prohibit such checks. On the
other hand, there are fields (e.g. Path) which are modified
during transport, and which are used in the protocol (at
least by some implementations, as discussed). It is
not unreasonable to recommend that these fields be checked,
so as to be able to pinpoint the agent responsible for
screwing up syntax or similar errors.  The questions then
are what might reasonably be checked, when, and by whom.  At
minimum, if a field is to be checked, the part which should
have been modified by the preceding (upstream) agent should
be checked.  If checking is a mere recommendation, then it
is possible that that upstream agent did no checking of what
was modified by its upstream neighbor and so on, so it
might be prudent to check everything that might have been
modified since injection.  Such checks (of modifications
made by predecessors) should probably be performed on
receipt, before other processing, so as to avoid attempting
to process broken articles. There is little point in an
agent attempting to check its own modifications prior to
sending an article downstream, since an author's error in
interpretation of requirements when modifying a field is
likely to be repeated when checking.  It is also conceivable
that an injection agent may have made an error, so there is
no reason to preclude a relay agent from checking parts of
fields that might have been set at injection time, or entire
fields that are supposed to be set at injection and remain
unmodified thereafter.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Oct 2004 12:23:48 GMT

>even those terms are not terribly forceful).

Indeed, but "RECOMMENDATION" is usually taken as something more than mere
"recommendation". The phrase Henry would use (and I have seen it used also
by yourself) is that SHOULD is a "strong recommendation" not lightly to
be ignored, and RFC 2119 supports that interpretation.

>requirements where performance is not the major issue.

But the question here relates to the behaviour of relaying agents, where
performance is THE major issue.

>during transport.

Indeed, and that is the case here. These headers are supposed to have been
checked already by an injecting agent (but there are some dodgy injecting
agents out there).

> ... On the
>screwing up syntax or similar errors.

But again, there is a performance hit here. What relaying agents do in
practice, I suspect, is just to extract anything that looks like a
path-identity and do a crude comparison with the identity of the site it
is about to relay to. No great harm arises if it gets it wrong
occasionally.

-- 
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: [email-masked]      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