headers
Charles Lindsey | 11 Mar 2002 10:56
Picon
Picon

Re: Sender header

In <Gsq1q3.1AG <at> clw.cs.man.ac.uk> Clive D.W. Feather (clive <at> demon.net) writes:

>However, I've figured out what was nagging me about this. The assumption
>throughout this discussion has been that the reason injectors add Sender:
>is for traceability. When this is the case (and it often is),
>Injector-Info: is better. However, this wording fails to allow for other
>situations.

>Try this:

>          NOTE: The addition of non-mandatory headers by the injecting
>          agent may alter the posting agent's preferred presentation of
>          information. In particular, adding a Sender-header that exposes
>          a sender's mailbox has privacy implications; where the main or
>          only purpose for doing so is as tracing information, it is
>          preferable for injecting agents to instead use one of the
>          options provided for the Injector-Info header (6.19.1).

Well yes, but not with that split infinitive :-( .

I now have:

        NOTE: The addition of non-mandatory headers by the injecting
        agent may alter the posting agent's preferred presentation of
        information. In particular, adding a Sender-header that exposes
        a sender's mailbox has privacy implications; where the main or
        only purpose for doing so is as tracing information, it is
        preferable to use instead one of the options provided for the
        Injector-Info header (6.19.1).
(Continue reading)

Permalink | Reply | 117 comments |
headers
Unknown | 22 Mar 2002 18:57

Re: Comments on draft-ietf-usefor-article-06.txt

# On Fri, 22 Mar 2002, Bruce Lilly wrote:
# > > I am seriously wondering if we should move to using a visible date-time.
# > > It eliminates most of these arguments. If you want something easy to
# > > parse, use ISO 8601 format: "2002-03-22T09:57:15Z".
# > 
# > Given the fact that software handling Usenet articles already has
# > to be able to parse RFC 822/2822 date-time (in Date and Expires
# > headers)...
# 
# Bruce has a good point here:  implementations already need one date
# parser, let's not force them to add another.
#                                                           Henry Spencer
#                                                        henry <at> spsystems.net

It does seem a waste of effort to have to implement multiple parsers 
to support different date formats in different headers...

--

-- 
Kent Landfield                        Phone: 1-817-545-2502
Email: kent <at> landfield.com             http://www.landfield.com/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/
Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 1 Mar 2002 12:06

Re: Not News Standard, was Re: Sender header

Russ Allbery said:
>> Thanks so much for pointing out where my paraphrase was wrong, or how
>> the argument I made based on it was wrong.

> I'm not interested in correcting your paraphrases after the fact.  I'm
> interested in not having my e-mail messages rewritten into a completely
> different tone and argument and then put forward as something that I
> believe.

Let me second this.

In fact, let me give an example. I initially wrote:

| I'd like it to be clear that "entity" doesn't mean "a specific human
| being", because that's about the only valid point I've seen John Stanley's
| stuff produce.

John replied with:

| So you'd like it specified that "entity" cannot be a human being just to
| spite me?

When I challenged it, he wrote:

| You don't seem to understand what
| the consequences of those words are, but they come straight from you.      
and:
| "Entity" can mean any one of several        
| things, one of which includes "human being".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 1 Mar 2002 12:18

Re: Sender header

Brian Palmer said:
> > Exactly so. Just to keep us all on track, here is the exact wording we are
> > concerned about:
> > 
> >    10.  The injecting agent MAY add other headers not already provided
> >         by the poster, but SHOULD NOT alter, delete or reorder any
> >         headers already present in the article, except that existing
> >         headers intended for tracing purposes, such as Injector-Info and
> >         Complaints-To, are to be removed as already mentioned.  The
> >         injecting agent MUST NOT alter the body of the article in any
> >         way.
> 
> This sentence is somewhat confusing, in that it zigs and zags. How about
> 
>         The injecting agent MAY add other headers not already provided
>         by the poster, but SHOULD NOT alter, delete, or reorder any
>         non-tracing header. The injecting agent MUST NOT alter the
>         body of the article in any way.

You've lost a bit too much of the detail. Try this:

          The injecting agent MUST NOT alter the body of the article in
          any way.  It MAY add other headers not already provided
          by the poster, but SHOULD NOT alter, delete, or reorder any
          existing header other than "tracing" headers (such as
          Injector-Info and Complaints-To, q.v.).

or:
          ...
          existing header, with the specific exception that it may remove
(Continue reading)

Permalink | Reply | 6 comments |
headers
Clive D.W. Feather | 1 Mar 2002 12:27

Re: Sender header

Just to make this completely clear:

John Stanley said:
[...]
>> He said that "entity" is not _defined_ 
>> to mean "a specific human being".
> 
> That is not what he said. The words were included in what you quoted.

The exact words in my outgoing mail log are:

| I'd like it to be clear that "entity" doesn't mean "a specific human
| being",

> He
> said "does not mean", not "is not defined to mean".

I did not use the word "defined", true, though I though it was clear in
context. However:

> He said, in essence,
> "there is a list of things an entity can be, and we should make it clear
> that that list does not inclulde 'human being'."

No, that's your strawman. I said '"a specific human being"'. That is not,
in essence or otherwise, the same as 'human being'.

Once again, please do not paraphrase or misquote me.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Mar 2002 12:14
Picon
Picon

Re: quoted strings within quoted strings

Here is another reply I received when I raised Clive's
posting-sender-parameter on the ietf-822 list.

>Date: Thu, 28 Feb 2002 12:39:02 -0500
>From: Cyrus Daboo <daboo <at> cyrusoft.com>
>Subject: Re: quoted strings within quoted strings
>Message-ID: <2147483647.1014899942 <at> [10.0.1.2]>

Hi,

--On Thursday, February 28, 2002 4:33 PM +0000 Charles Lindsey
<chl <at> clw.cs.man.ac.uk> wrote:

| So what is the proper way to do it?
| Would it be
| 
| 	sender = "\"John D. Bloggs\" <jdbloggs <at> example.com>"
| 
| in which case would/should the inner \"John D. Bloggs\" then be
| interpreted as a quoted-string?
| 
| Or is it the case that there is no proper way to express this sort of
| thing?

I think you need a slightly different example to actually express this
problem. If the phrase had instead been 'John D. "Cool" Bloggs', then you
have the problem of a quoted string in a quoted string more clearly
expressed, and I think the simple solution is to reapply the quoting rules
so you end up with something like:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Mar 2002 12:12
Picon
Picon

Re: quoted strings within quoted strings


I enquired on the ietf-822 list regarding the problem Clive raised with
the syntax of the posting-sender-parameter. Here is a reply received from
Keith Moore. I think I can build that sort of mechanism into our draft
without too much difficulty.

>Message-Id: <200202281732.g1SHWaF22699 <at> astro.cs.utk.edu>
>From: Keith Moore <moore <at> cs.utk.edu>
>cc: ietf-822 <at> imc.org
>Subject: Re: quoted strings within quoted strings 
>In-reply-to: (Your message of "Thu, 28 Feb 2002 16:33:33 GMT.") 
>             <Gs94nx.3pI <at> clw.cs.man.ac.uk> 
>Date: Thu, 28 Feb 2002 12:32:36 -0500

> So what is the proper way to do it?
> Would it be

        sender = "\"John D. Bloggs\" <jdbloggs <at> example.com>"

IMHO yes.  and the value encded by that sender parameter is

"John D. Bloggs" <jdbloggs <at> example.com>

not

\"John D. Bloggs\" <jdbloggs <at> example.com>

Keith

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Djernaes | 1 Mar 2002 15:56
Picon
Favicon

Replying to a message

Hi,

I'm digging into a can of worms, I think, but anyway.

In section 5.4 of the draft you write about the subject field, and how to
modify this one when replying to a mail. I read that you want to "forbid"
non "latin" versions of the prefix "Re: ".

Could you please explaing the reason for this? I didn't find (enough)
information about this in the archive.

The reason for my interrest into the subject, is the fairly widespred
ignorance from people supporting this view. I don't see any (technical)
reason for this, and cannot follow why "common practice" can't be an
accepted behavioiur. Sure, there is an old rfc saying that Re: had been
implemented, but there shouldn't be anything stopping this expansion if the
functionallity.

I don't understand why the subject field is being seen as a field for
"computers" to read. The subject is mainly a display field for the human
eye. Sure, some kind of processing of the field can/will be done, but since
this is for display a minor "error" won't have any effect on the
functionallity.

Hope that someone can enlighten me on this point.

Regards,
  Martin Djernaes

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Djernaes | 1 Mar 2002 02:31
Picon
Favicon

Replying to a message

Hi,

I'm digging into a can of worms, I think, but anyway.

In section 5.4 of the draft you write about the subject field, and how to
modify this one when replying to a mail. I read that you want to "forbid"
non "latin" versions of the prefix "Re: ".

Could you please explaing the reason for this? I didn't find (enough)
information about this in the archive.

The reason for my interrest into the subject, is the fairly widespred
ignorance from people supporting this view. I don't see any (technical)
reason for this, and cannot follow why "common practice" can't be an
accepted behavioiur. Sure, there is an old rfc saying that Re: had been
implemented, but there shouldn't be anything stopping this expansion if the
functionallity.

I don't understand why the subject field is being seen as a field for
"computers" to read. The subject is mainly a display field for the human
eye. Sure, some kind of processing of the field can/will be done, but since
this is for display a minor "error" won't have any effect on the
functionallity.

Hope that someone can enlighten me on this point.

Regards,
  Martin Djernaes

--

--
(Continue reading)

Permalink | Reply | 4 comments |
headers
Clive D.W. Feather | 1 Mar 2002 16:35

Re: Replying to a message

Martin Djernaes said:
> In section 5.4 of the draft you write about the subject field, and how to
> modify this one when replying to a mail. I read that you want to "forbid"
> non "latin" versions of the prefix "Re: ".
> 
> Could you please explaing the reason for this? I didn't find (enough)
> information about this in the archive.

In theory you should be able to tell the start of a thread from a
continuation article by looking for a References header. However, in
practice such headers are often missing. By reserving the "Re: " prefix for
followups, the draft provides some useful redundancy, redundancy that
newsreader software already takes advantage of.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change
Permalink | Reply | 1 comment |

Gmane