headers
Chris Newman | 1 Apr 1999 01:53

Re: Signed headers in email (was Re: Draft for signed headers)

On Fri, 26 Mar 1999, Charles Lindsey wrote:
> >(4) Any attempt at a canonicalization algorithm for mail header signing is
> >    doomed to failure from the outset.  It will be ambiguous, too complex,
> >    or inadequate.
> 
> And that is a matter you decide by examining the proposals and finding
> holes in them. Not by asserting ex cathedra that no solution exists. I
> have proposed a canonicalization algorithm which may or may not work. It
> should be examined, discussed, and improved.

I skimmed your proposal and it was both too complex and had ambiguities. 
The obvious way to simplify it is to stop worrying about email-safety. 
It's not worth pointing out the ambiguities until the algorithm is
sufficiently simple to be viable.

> Fine. So you are happy to let the news people develop this tool on their
> own, and you are not going to complain if it turns out later that they
> have omitted some small tweak that would have made it work much better in
> mail?

Yes.

> That is fine by me. But we shall in any case try to make it as
> mail-proof as we can while we are about it.

If you really want this to work in news, I suspect the KISS principle is
far more important than "mail-proof".

		- Chris
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 1999 03:30
Picon
Favicon
Gravatar

Re: Draft v2 comments

Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

> No, it's in the draft at the moment, and should stay there for now.
> Judging by my experience in trying to get the email people to work
> jointly on Signed Headers, it is better not to try (there seems to be a
> belief in the email fraternity that they invent features and we adopt
> them, rather than the other way around :-( ).

You're generalizing from a crypto/authentication problem to all other
problems, at least in the above paragraph (I realize that there has been
other interaction with the mail standards in the past).  I'd recommend not
doing that; crypto stuff is a special category of headaches all to itself.

We've successfully done joint mail and news drafts before for other
things; I really think that User-Agent needs to have a broader scope than
just Usenet.  But I'll drop the topic for right now as it's not what we're
currently talking about.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
Brad Templeton | 1 Apr 1999 05:14
Picon

Re: Draft v2 comments

On Wed, Mar 31, 1999 at 06:39:21PM +0000, Charles Lindsey wrote:
> In <yl3e2n9uuj.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:
> 
> >Wasn't Author-ID the header that was intended to be persistent and serve
> >as a solution for the problem of "I want to score up all responses to my
> >articles"?  I don't feel too strongly about it one way or the other, since
> >now that we're not requiring the server to generate message IDs I can
> >continue doing this entirely with overview information and
> >client-generated message IDs as always, but that was the intended purpose
> >as I recall.
> 
> Yes, and we were pretty well agreed on it at the time. It looks a tidy
> solution to the problem, and the tail of the Path line is liable to misuse
> in so many other ways that it is best not relied on. We agreed that it
> needs support by followup agents, so that acceptance in the community will
> be slow, but that is all the more reason to get it started early. I would
> like to see it in the draft. It is not rocket science like some of our
> more advanced imaginings.

Are we talking about the same thing?  I thought there was a proposal for
a header (author-id) for injectors to put in diagnostic information about
what they did, including information on the poster (like nntp posting host or
a userid) and a few other rare cases.    Is this a different header
under proposal?  I track responses to my messages by just remembering
my message-ids, and noting when they appear in references.  I don't see
a need (or an easy way to do) a header for that.

As far as an author-id to identify users, I still maintain that 99.9% of
the proposed purpose is already attained in the path line.  Can you
be more specific about your claim that the path line is liable to
(Continue reading)

Permalink | Reply | 15 comments |
headers
Russ Allbery | 1 Apr 1999 05:39
Picon
Favicon
Gravatar

Re: Draft v2 comments

Brad Templeton <brad <at> templetons.com> writes:

> Are we talking about the same thing?  I thought there was a proposal for
> a header (author-id) for injectors to put in diagnostic information
> about what they did, including information on the poster (like nntp
> posting host or a userid) and a few other rare cases.  Is this a
> different header under proposal?  I track responses to my messages by
> just remembering my message-ids, and noting when they appear in
> references.  I don't see a need (or an easy way to do) a header for
> that.

Author-ID in the proposal would be persistant.  You can't easily remember
your message IDs if you don't generate them in the client, plus you get
score file bloat by doing it that way.  For expansions on both of those
comments, please see the list archives, since we had an *extremely*
extended discussion of this some time back that covered all of the issues,
pluses, and minuses.

> As far as an author-id to identify users,

I think we have enough headers to identify users, although I think we need
to canonicalize something like the existing X-Trace header and formally
replace NNTP-Posting-Host with something like it (and we probably should
make it extensible and let the information contained therein be tagged,
which probably means going to MIME attribute format as annoying as that
is).  In any event, that wasn't the purpose of Author-ID as I understood
it.

I have comments on the rest of this, but I'd rather save them until we get
to the point where we're discussing the duties of an injecting agent.  (I
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Grobe | 1 Apr 1999 06:00
Picon

Re: Draft v2 comments

It was the Originator-Info header which you are thinking of Brad,
which is to mostly come from Newman's draft.

Jonathan Grobe

On Wed, 31 Mar 1999, Brad Templeton wrote:
> 
> Are we talking about the same thing?  I thought there was a proposal for
> a header (author-id) for injectors to put in diagnostic information about
> what they did, including information on the poster (like nntp posting host or
> a userid) and a few other rare cases.    Is this a different header
> under proposal?
Permalink | Reply | 11 comments |
headers
Brad Templeton | 1 Apr 1999 06:13
Picon

Re: Draft v2 comments

On Wed, Mar 31, 1999 at 07:39:18PM -0800, Russ Allbery wrote:
> Brad Templeton <brad <at> templetons.com> writes:
> Author-ID in the proposal would be persistant.  You can't easily remember
> your message IDs if you don't generate them in the client, plus you get
> score file bloat by doing it that way.  For expansions on both of those
> comments, please see the list archives, since we had an *extremely*
> extended discussion of this some time back that covered all of the issues,
> pluses, and minuses.

How can it be persistant?   You could keep the author of the original
root of the thread around but what's the point in that.

I simply will have to contradict your statement that it's hard to remember
your own message-ids.  That's exactly what my own tool does, and it is
not difficult.   Since any such tool is, one presumes, reading the newsgroups
you post to, it's not exactly hard for it to notice your own name(s) in the
From line and remember the message-ids, which is what I did.  It was about
5 lines of newsclip code to do the whole thing.

> I think we have enough headers to identify users, although I think we need
> to canonicalize something like the existing X-Trace header and formally
> replace NNTP-Posting-Host with something like it (and we probably should
> make it extensible and let the information contained therein be tagged,
> which probably means going to MIME attribute format as annoying as that
> is).  In any event, that wasn't the purpose of Author-ID as I understood
> it.

Why is the MIME format annoying?  Experience shows that named parameters are,
for a small amount of extra bulk, much superior to positional parameters.
First of all you write one parser which can be used to parse any header
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brad Templeton | 1 Apr 1999 06:16
Picon

Re: Draft v2 comments

On Wed, Mar 31, 1999 at 10:00:06PM -0600, Jonathan Grobe wrote:
> It was the Originator-Info header which you are thinking of Brad,
> which is to mostly come from Newman's draft.
> 

My apologies.  I'm mostly arguing against that.  However, I see no
purpose in the Author-ID either.  You can't have a persistent author-ID
header, other than for either the author of the root or the author of
the immediate parent.  Other authors would need to be discarded (or make
a very big set of IDs)

Since it's pretty simple for any tool to, when scanning a newsgroup for
followups to one's postings, also detect one's own postings and remember
the message-id, I see no need for a persistent author-id.

Indeed, remembering your own message-ids is superior because you can track
all your followups.   This is in fact what my own clipping program did.
Permalink | Reply | 9 comments |
headers
Russ Allbery | 1 Apr 1999 06:25
Picon
Favicon
Gravatar

Re: Draft v2 comments

Brad Templeton <brad <at> templetons.com> writes:

> My apologies.  I'm mostly arguing against that.  However, I see no
> purpose in the Author-ID either.  You can't have a persistent author-ID
> header, other than for either the author of the root or the author of
> the immediate parent.  Other authors would need to be discarded (or make
> a very big set of IDs)

Brad, if you're going to keep discussing this and you really don't
remember the huge discussion we had about this before, please go read the
list archives so that you are at least familiar with where the discussion
left off.  We already talked about all this stuff.

> Since it's pretty simple for any tool to, when scanning a newsgroup for
> followups to one's postings, also detect one's own postings and remember
> the message-id, I see no need for a persistent author-id.

We already talked about this too.  I've already rebutted this point at
least twice; I really would rather not do it a third time when this should
all be in the archives.

Plugging "Author-ID" into the search box of the archives returns the
entire thread from last July.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 5 comments |
headers
Russ Allbery | 1 Apr 1999 06:45
Picon
Favicon
Gravatar

Re: Draft v2 comments

Brad Templeton <brad <at> templetons.com> writes:

> Why is the MIME format annoying?

I'm going to hold off on this and the discussion of NNTP-Posting-Host
until we reach that section of the draft.  I have quite a bit to say on
the subject and would rather that it be part of the main discussion of the
draft rather than as a continuing side discussion.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 1999 06:53
Picon
Favicon
Gravatar

Re: Abstract and 1. Introduction

Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

> This Draft defines the format of Netnews articles and specifies the
> requirements to be met by software which originates, distributes, stores
> and displays them. It is intended as a standards track document which
> will in due course supersede RFC 1036, which itself dates from 1987.

Recommend dropping "which will in due course" and just saying "...a
standards track document, superseding RFC 1036 which dates from 1987."
It's shorter, more direct, and reflects what this document will be when it
is published.

Apart from that, I like this abstract much better than the previous one.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 1 comment |

Gmane