headers
Frank Ellermann | 1 May 2007 09:14
Picon
Picon

Re: #1416 Injection-Date: current wording proposal (corrected)


Russ Allbery wrote:

> I think it may be worthwhile to reach consensus on several parts of
> this separately.

Yes, e.g. I've no clue what precisely you adopted from what I wrote,
or what I wrote in the first place.  Sometimes there are situations
where I think B is better than A, and as soon as I see B I think A
is better than B, etc. until somebody says enough.

> For example, if we decide that the whole current history section is
> fine, I can incorporate that into the draft and then stop including
> it in further diffs for discussion.

Checking what I recall, the "one day in the future" business is clear.

Apparently the definition of "retention" is based on the article date,
not the arrival date, is that as it should be ?  [[In the bullet with
the "optimization for easier history manipulation"]]

Maybe add a qualifier "if using the article date and not the arrival
date" to the "history retention" in this paragraph.

For the "MUST NOT contain POSTED", in theory this would be fine for
an injecting-agent not creating its own POSTED because it doesn't
know the new diagnostics.  But when it doesn't know them it can't
identify them, so I guess the MUST NOT is unnecesary.  Or I forgot
why we wanted this.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frank Ellermann | 1 May 2007 09:23
Picon
Picon

Re: Reject vs. fix


Harald Alvestrand wrote:

> My technical opinion:

> I think it's reasonable for a posting agent (under the control of the
> poster) to "fix" articles.
> I think it's unreasonable for an injecting agent (under the control of
> the news admin) to do so.

We didn't disagree, or did we ?  Maybe we're in violent agreement.

Frank
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 09:30
Picon
Picon

Re: OT: nslookup -q=soa bogus.bogus.com


Harald Alvestrand wrote:

>> `nslookup -q=soa bogus.bogus.com` results in an error
>> with my version of nslookup, it gives up for NXDOMAIN.

> I was talking about Charles' tree-climbing exercise; if you cut off
> labels until you find something, you will eventually look up ".com".

In his example he'd arrive at bogus.com (that exists) with tree
walking.  It's odd that there is no clear distinction between
the two cases "yes, this is my domain, and what I do below it
is none of your business" and "yes, this is my domain, but I'm
not responsible for anything below it that doesn't exist (yet)."

Frank
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 09:41
Picon
Picon

Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity


Charles Lindsey wrote:

> USEAGE could try to pick up the pieces.

If it starts by recommending _one_ news role acoount out of the
three proposals (two in 2142 + two in s-o-1036) it can try that.

In a parallel article you said about the "zone cut" odditites:

| Interestingly, the DKIM WG has been looking at this, and to
| do it properly you really need some widely publicised and
| maintained list of TLDs/zones.

The SURBL list is nice, but it's no IANA registry or something,
some entries in this list are there because I submitted them
(e.g. enum.arpa), IOW it's far from complete or reliable.  No
uri.arpa and no urn.arpa (examples) if it's still at the state
I know.

The CSV strategy was also cute, but it was a kludge, something
in the direction of "try direct, if that fails strip to seven
labels or what you have minus the already tested direct FQDN,
test that, and then test up to the SLD, never bother the TLD".

Don't nail me about CSV details, please.

Frank
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 May 2007 10:40
Picon
Picon

Re: #1416: Reinjection and Injection-Date proposed text


Russ Allbery wrote:

> Just for clarity in the discussion (I don't think a wording change is
> needed), note that the cutoff date for history retention is independent
> of the period of article retention in the spool.  Usually the latter is
> longer than the former, but it may also be shorter.  They don't need to
> be related.

Oops, now I've read and answered the corrected diff before I read this
article, some of my remarks there might be obsolete...

Yes, I thought that there's only one meaning of "retention", so please
ignore the remark / question about that.

>>| The posting agent MUST supply the Message-ID and the Date, it
>>| SHOULD also supply an Injection-Date, and the proto-article
>>| offered to each injecting agent MUST be identical.

>> Arguably you can also use MUST here as you have it, and replace
>> the "multi-SHOULD" at the end of 3.4.1 by MUST.  But that would
>> render all existing posting agents with no idea about the new
>> Injection-Date as "non-conforming" when they try multi-Injection.

> As mentioned above, I went the MUST route, but I think it's a debatable
> point and I'd love to hear other comments.

Okay, if it's consistent I can certainly live with both, and the
MUST route results in clearer text.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Alvestrand | 2 May 2007 16:08
Picon

Re: #1416 Injection-Date - Summary of options


Charles Lindsey wrote:
>
>> After writing the text, I think it's weird, but it's not quite as bad as I
>> thought it was going to be.  It does have the merit of closely mirroring
>> how Date works today, and if we're going to change something in this area,
>> sticking as close to what we know works as possible seems like a good idea
>> to me.
>>     
>
> +1
>
> It may well be that most 'normal' posting agents leave it to the injecting
> agent, but for the guy who is doing something slightly out of the ordinary
> (multiple injection, delayed injection, etc) it does have some advantages,
> and I can't see any disadvantage.
>   
As long as we assume that no posting agent ever sees an advantage to 
creating an injection-date with false information, and that the number 
of posting agents who generate wrong injection-date parameters is not 
significantly higher than the number of injecting agents to do so, there 
are no disadvantages I can see.

Those two assumptions are fairly big.

                  Harald
Permalink | Reply | 6 comments |
headers
Russ Allbery | 2 May 2007 19:40
Picon
Favicon
Gravatar

Re: #1416 Injection-Date - Summary of options


Harald Alvestrand <harald <at> alvestrand.no> writes:

> As long as we assume that no posting agent ever sees an advantage to
> creating an injection-date with false information, and that the number
> of posting agents who generate wrong injection-date parameters is not
> significantly higher than the number of injecting agents to do so, there
> are no disadvantages I can see.

> Those two assumptions are fairly big.

I don't see any possible advantage for a posting agent creating a false
Injection-Date header over a posting agent right now creating a false Date
header.  They should be equivalent.  The Injection-Date header is
functional, rather than a trace header.

Trace information should be put in Injection-Info instead.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 2 comments |
headers
Russ Allbery | 2 May 2007 19:51
Picon
Favicon
Gravatar

ISSUE: 4.2. Moderation flag in checkgroups


Julien ÉLIE pointed out in private e-mail a minor problem with how the
moderation flag is specified in section 4.2.  Currently, we have:

         newsgroups-line     = newsgroup-name
                                  [ 1*HTAB newsgroup-description ]
                                  [ 1*WSP moderation-flag ]
         newsgroup-description
                             = eightbit-utext *( *WSP eightbit-utext )
         moderation-flag     = %x28.4D.6F.64.65.72.61.74.65.64.29
                                  ; case sensitive "(Moderated)"
         eightbit-utext      = utext / %d127-255

This allows a tab before "(Moderated)" instead of a space.  I'm not sure
that existing software supports that, it doesn't match the informal
description on ftp.isc.org, and it contradicts the text in the following
paragraph:

   The <newsgroup-description> MUST NOT contain any occurrence of the
   string "(Moderated)" within it.  Moderated newsgroups MUST be marked
   by appending the case sensitive text " (Moderated)" at the end.

I propose changing the newsgroups-line production to instead read:

         newsgroups-line     = newsgroup-name
                                  [ 1*HTAB newsgroup-description ]
                                  [ *WSP moderation-flag ]

and moderation-flag to read:
(Continue reading)

Permalink | Reply | 566 comments |
headers
Russ Allbery | 3 May 2007 04:59
Picon
Favicon
Gravatar

Re: #1416: Reinjection and Injection-Date proposed text


Charles Lindsey <chl <at> clerew.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> writes:

>> Just for clarity in the discussion (I don't think a wording change is
>> needed), note that the cutoff date for history retention is independent
>> of the period of article retention in the spool.  Usually the latter is
>> longer than the former, but it may also be shorter.  They don't need to
>> be related.

> You surprise me. I would have expected the article period retention to
> be used if longer than the cutoff, on the grounds that, if you still
> have the article stored, then it is easy to detect that anotherone that
> arrives should be ignored.

Since articles are not usually stored by message ID, most implementations
will not find it any easier to verify that they already have an article
when the article is still in the spool.

However, related to that, INN and CNews both use the history file for
various protocol operations, such as retrieving articles by message ID.
There's no inherent need to use the history file for this purpose; it just
happened to be convenient to extend it with a few additional fields since
it was already keyed by message ID.  This is just an implementation
detail, and it's fair game to have the history entirely independent of the
local spool.

That wasn't really what I was driving at, though.  What I was saying was
that the cutoff period for history entries (how long they're retained
regardless of whether the article is still stored) is often shorter than
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 3 May 2007 05:05
Picon
Favicon
Gravatar

Re: #1416 Injection-Date: current wording proposal (corrected)


Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

> Apparently the definition of "retention" is based on the article date,
> not the arrival date, is that as it should be ?  [[In the bullet with
> the "optimization for easier history manipulation"]]

> Maybe add a qualifier "if using the article date and not the arrival
> date" to the "history retention" in this paragraph.

Is this part clear now?

> For the "MUST NOT contain POSTED", in theory this would be fine for an
> injecting-agent not creating its own POSTED because it doesn't know the
> new diagnostics.  But when it doesn't know them it can't identify them,
> so I guess the MUST NOT is unnecesary.  Or I forgot why we wanted this.

I'm not sure that it was a matter of a lot of on-list discussion.  It feel
out of a tighter definition of just what a proto-article is, and I may
well have made it too tight.  It's a trace diagnostic, so having it
multiple times doesn't hurt anything.

I think we either say that an injecting agent MUST reject articles that
already have POSTED or we drop that wording entirely; I don't think a
SHOULD would make sense.

> You still have 72 hours, can we use 3 days, getting rid of "hours"
> everywhere ?  And MUST NOT instead of SHOULD NOT about the minimum, I
> don't see how it can work as expected for a seriously shorter periods,
> or what's a good excuse for shorter periods.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane