[Top] [All Lists]

Re: 3028bis, section 4.2, paragraph 2

2007-02-08 16:29:46

On Wed, Feb 07, 2007 at 09:21:49PM -0700, Philip Guenther wrote:

Mark Mallett wrote, in regards to this text in 3028bis-10, section 4.2:


I'd like to stress that the *critical* thing in that paragraph is the bit 
about "count of 'received's MUST be higher", as that's what provides a way 
to break loops.

Ah... I didn't get that connection at all.  OK, there is the text later
in that section:

   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting Received

So it sounds like you are saying that the new text about how the count
of Received headers MUST be larger is connected to that.  That since
some implementations may choose to count Received lines to avoid loops,
all implementations must have a higher Received line count when doing
redirect.  I don't see that as a valid prescription, I think that the
"take measures to implement loop control" is enough (especially since I
don't really think that Received-line counting is all that great a

I don't mean to be anal (other than it coming naturally, perhaps),
but I just don't see that as a valid justification for the MUST.
(Even though I am in favor of implementations adding a Received line.)


I hope I'm not coming across as trying to dodge the issues here.

And again I hope I'm not being a pain.  However the text I commented on
is new as of -10, so it seems [more] reasonable to comment on it.  It
may be that everyone decides it's a non-issue... so be it.

At any rate I feel conflicted:  I like the idea of recommending that
implementations add a Received line, but not in the "redirect" section.
Evidently it's too late for that.  I not wild about the new MUST in the
redirect section, especially now having learned that its only reason for
being there is for loop control.  (I could probably even imagine good
reasons for removing some Received lines prior to redirect-- but I

My 2c...


<Prev in Thread] Current Thread [Next in Thread>