headers
Greg Berigan | 1 Mar 1998 03:52
Favicon

Re: Draft 0.5: User-Agent

Draft 0.5: User-Agent

Changes:
	- got rid of the policy-enforcement function of User-Agent
	- explained how its presence
	- deferred to [MESSFOR-03] for the syntax of comments, and allows
	  for lack of spaces between products and comments, but spaces
	  must be present between bare comments... further changes to
	  Basic Format due to [MESSFOR] should be watched carefully
	- corrected my misimpression regarding {}s
	- made it clearer wrt to the examples that servers can have their
	  products mentioned in the header by injecting agents but not by
	  themselves by creation of the header nor modification.

5.17.  User-Agent

   The User-Agent header contains information about the user agent
   (typically a newsreader) generating the article. This is for
   statistical purposes and tracing of standards violations to
   specific software needing correction.  Although OPTIONAL, user
   agents SHOULD include this header with the articles they generate.

   The field MAY contain multiple product tokens and comments
   identifying the agent and any subproducts which form a significant
   part of the user agent such as external agents used for message
   composition, separated injecting agents (such as those used by
   offline newsreaders), and significant libraries that are part of
   such agents. The products are listed in order of their significance
   for identifying the application, not necessarily in chronological
   order of handling prior to injection.  Injecting agents MAY include
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Babel | 1 Mar 1998 12:23
Picon

Re: Control header and Control messages v.01

Claus André Färber wrote:

> No need for Also-Control, the server just has to file
> it into the regular group in addition to control.*.

I'm certainly not against that. See archive/latest/2888.
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Mar 1998 12:55
Picon
Picon

Re: DRAFT - Basic Format v0.3

In <6og79IkocDB <at> faerber.muc.de> usenet-format-list <at> faerber.muc.de
(=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=) writes:

>Then put the information in headers, but not in the text body. However I =
>=20
>still believe that this information is not useful enough to have it on =20
>every message. Why not send the whole original message in a second part =20
>of the reply?

But it is not suggested that it (the message-id of the precursor) should
be required in every followup message. Just that IF it is included, then
it should be in the given format. The plain fact is that many current
followup agents DO include this information, and will likely continue to
do so.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing-------------------------
Email:     chl <at> clw.cs.man.ac.uk   Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506       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
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Mar 1998 13:06
Picon
Picon

Re: DRAFT: v.04 Control header and Control messages

In <Pine.LNX.3.95.980301115950.23914w-100000 <at> darkmere.gen.nz> Simon Lyall
<simon <at> darkmere.gen.nz> writes:

>x.1 cancel

>The cancel message requests that one or more target articles be 
>"cancelled" ie be withdrawn from circulation or access. This message MAY
>be issued by entities which processed the target article(s) while it was 
>still a proto-article (ie posters, posting agents, moderators and 
>injecting agent. See also Gateways[xxx] ). Other entities MUST NOT use
>this method to remove articles.

>NOTE: A separate method for other entities to cancel articles will be
>defined in a later draft.

Don't like that MUST NOT for other entities, nor the suggestion that some
separate control message will be provided for their use. This flies in the
face of existing practice. Moreover, that practice may well evolve over
time, and works by "common consent" and "accepted usage" rather than by
application of any specific rules. This is as it should be. It is a grey
area that seems to be necessary and to work reasonably well at the present
time. Our standard should neither condone nor forbid such practices. We
just need to make sure that it is possible to recognise 3rd party cancels
for what they are, and to be able to determine with reasonable certainty
where they came from.

I would suggest simply omitting that MUST NOT sentence for the next draft,
and modifying the note to indicate that this area is still subject to
discussion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Mar 1998 13:24
Picon
Picon

Re: DRAFT: v0.7 Duties of various agents

In <Pine.LNX.3.95.980301120840.23914x-100000 <at> darkmere.gen.nz> Simon Lyall
<simon <at> darkmere.gen.nz> writes:

>x.1 Duties of an Injecting Agent.

>To this end injection agenst MAY cancel articles which they have
>previously injected.

Yes, I am happy that the guaranteed authority to cancel ends at the
injecting agent's site, but please - it is not the injection agent that
cancels the article, but rather the sysadmin at the injecting agent's
site. We have the distinction between poster/posting agent, and elsewhere
your text refers to the HUMANS (poster or moderator) entitled to cancel,
so it should be a HUMAN that is referenced here.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing-------------------------
Email:     chl <at> clw.cs.man.ac.uk   Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506       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
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Mar 1998 13:19
Picon
Picon

Re: DRAFT: v0.6 Duties of various agents

In <Pine.LNX.3.95.980301100213.23914v-100000 <at> darkmere.gen.nz> Simon Lyall
<simon <at> darkmere.gen.nz> writes:

>On Fri, 27 Feb 1998, Charles Lindsey wrote:
>> 
>> >A proto-article MUST NOT contain the "!" or "%" character in the
>> >Path header. 
>> 
>> No, I don't see what is wrong with a "!". Brad's text certainly allows it.

>Brad's text allows the use of "," as well.. (or just about anything else
>for that matter). 

Indeed, but in that case why forbid "!" specifically. Brad makes it clear
that there is a distinction between the stuff before the "%" and the stuff
after it, but I see no particular reason to say anything about what
separators are or are not appropriate after the "%", except that another
"%" would be out of order.

>> It would be appropriate where an article has wandered around some intranet
>> before reaching the injecting agent,

>In which case it has already been injected since (a) It has all the
>headers , (b) it has more than a single Path entry and (c) More than one
>copy MAY exist.

Not necessarily so if the intranet is star shaped, with the injector at
the centre. Suppose some home user has several computers around the house
networked together, and one of them is used to dial up the ISP (the ISP
does the injecting). Then I would be happy to see
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Grobe | 4 Mar 1998 21:07
Picon

Where is the draft?

If the draft has to be submitted for publication on March 12, why 
hasn't a preliminary version been posted yet?

Jonathan Grobe.
Permalink | Reply | 1 comment |
headers
Dan Ritter | 5 Mar 1998 14:34

Re: Where is the draft?

At 02:07 PM 3/4/98 -0600, Jonathan Grobe wrote:
>If the draft has to be submitted for publication on March 12, why 
>hasn't a preliminary version been posted yet?

Because it isn't done yet, of course. I'm dedicating the next several
nights and this weekend to it; I hope to be posting on Sunday night.

-dsr-
Permalink | Reply | 0 comments |
headers
Simon Lyall | 5 Mar 1998 15:27
Picon
Favicon
Gravatar

Last Call: The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews to Proposed Standard (fwd)

In case people missed this. The basic headers look close to what we have,
I havn't done a line-by-line on the syntax but obviously it misses the
UTF8 stuff..

-- 
Simon Lyall. |  Looking for Work  |  Mail: simon <at> darkmere.gen.nz
"To stay awake all night adds a day to your life" - Stilgar | MT.

---------- Forwarded message ----------
Date: Thu, 05 Mar 1998 07:02:47 -0500
From: The IESG <iesg-secretary <at> ns.ietf.org>
Reply-To: iesg <at> ns.ietf.org
To: IETF-Announce:  ;
Subject: Last Call: The Auto-Submitted, Supersedes and Expires Headers  in E-mail and Netnews to Proposed Standard

The IESG has received a request to consider The Auto-Submitted,
Supersedes and Expires Headers in E-mail and Netnews
<draft-ietf-mailext-new-fields-12.txt> as a Proposed Standard.  This
has been reviewed in the IETF but is not the product of an IETF Working
Group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by April 11, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mailext-new-fields-12.txt
Permalink | Reply | 0 comments |
headers
Chris Newman | 6 Mar 1998 20:08

Re: DRAFT - MIME headers v0.1

[Sorry I didn't get back to you on this sooner -- I've been busy]

On Thu, 12 Feb 1998, Charles Lindsey wrote:
> >If you want to list them all, don't forget:
> >      Content-Disposition:
> >and   Content-MD5:
> 
> I did not see these in RFC 2045. Please can you point me at the RFC where
> they are defined (as extensions, I presume)?

Content-MD5 is RFC 1864 and is a Draft Standard.
Content-Disposition is RFC 2183 and is a Proposed Standard.

> I don't want to place a burden on posting agents to have to scan the
> entire article to check whether it contains an eighth bit anywhere.
> Gateways may need to do this check if they feel obliged to downconvert.
> Note that most existing posting agents can be made compliant by
> configuring them to insert Encoding: 8bit and charset=iso-8859-1
> regardless. There are a lot of existing posting agents around that will
> still be around for some considerable time.

I'm inclined to say that posting agents will have to scan the entire text
for one reason or another (e.g., to wrap lines or map the native charset
to UTF-8).  It's probably more important to allow gateways to convert in a 
single pass than to permit a posting agent which happens to use UTF-8 as
its native charset to send without a scan of the text.  I'll also mention
that if a message is sent via SMTP then 7-bit CTE MUST be used when
possible.  Since most posting agents include SMTP support, it's simpler
to make the behavior consistant.
(Continue reading)

Permalink | Reply | 8 comments |

Gmane