NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Simon Lyall <simon@darkmere.gen.nz>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:usenet-format@clari.net
To Subscribe: usenet-format-request@clari.net
In Body: subscribe your.email.address in Subject field
Archive: http://www.landfield.com/usefor/
Description of Working Group:
Motivation
The Standard for Interchange of USENET Messages, defined in RFC 1036, was released in December 1987. This RFC defines the format that format that all usenet articles must follow (similar to the way RFC 822 does for email) and also covers the algorithm that is used to distribute usenet articles. Since that time there has been no official update published despite the rapid growth in Usenet and other networks that use the RFC 1036 article format.
A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard.
At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard.
At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives.
In particular the following areas need urgent attention:
- Standards for the signing of articles (sign-control and PGP-MOOSE) - Authentication of cancels. - Use of non-ASCII character sets in article headers and bodies - Standardization of article bodies and the use of MIME in articles. - Standardization and extension of 3rd party control messages affecting articles (NOCEM) - General revision of various limits (eg article size) listed in previous standards.
and many other aspects of the standards need reviewing.
Description
The Goal of this working group is to publish a standards-track successor to RFC 1036 that with particular attention to backward compatibility, formalizes best current practice and best proposed practice. The Group shall also aid and/or oversee the production of other Usenet related Internet Drafts and Standards.
The Working Group shall:
1. Produce an Internet Draft (or series of drafts) that describes the core standards for a Usenet article and the features that all Usenet software should take account of.
2. Produce a group of Internet Drafts formally describing extensions to the core standard for a Usenet article (see above).
3. Produce a further Internet Draft that incorporates the core standard for a Usenet article (see 1) plus all those extensions (see 2) that the working group believe should become part of a final standard.
4. Publish a standards-track successor to RFC 1036 that formalizes best current practice and best proposed practice.
5. Publish any other extensions to the Usenet Article Standard that warrant being formal extensions but are outside the scope of the main standard.
Goals and Milestones:
Nov 97 |
|
Identify areas where extensions are required and write I-D on minimum standards |
Dec 97 |
|
Revise Internet-Draft of minimum standard |
Feb 98 |
|
Produce a revised internet-draft of the Usenet Article Standard incorporating the minimum standard and extensions produced above. |
Jun 98 |
|
Submit the revised Usenet Article Standard to the IESG for Proposed Standard status. |
Jul 98 |
|
Submit to the IESG any extensions to the Usenet Article Standard for Proposed Standard status. |
Internet-Drafts:
· Identification of messages delivered via both mail and news
No Request For Comments
USEFOR at IETF 42 Meeting Notes
About 20 people attended, including both Area Directors (Apps).
1. Message IDs:
After mild discussion, consensus says this is ready for publication as an
Informational RFC.
2. Posted-And-Mailed
Discussed in two parts.
First, debate over the actual texts:
Why do we ignore followups-to in mail messages?
We should add a requirement for handling Newsgroups header in mail if Posted-
To header is not present.
Why is Newsgroup header included in mail reply if it's not posted to newsgroup?
Apparently, there is ambiguity in how this has been handled. Some MUA/reader
agents have interpreted this as "This is a response to a news article" and others have
thought it to mean "This is also being sent via news.
ACTION-ITEM: Chris Newman will mail Jamie some feedback on these issues.
Part Two: Many issues regarding mixing mail and news
The obvious: we need to be careful mixing them.
Some folks (Eric Fair, among others) are really opposed to ever mixing them.
In general USEFOR seems to agree that end users do want to mix the two.
Do we want a header that signfies it's both a mail-n-news header?
Problems exist: reply-to-via-email msg from a newsgroup - is this a good thing?
A new message sent to both a newsgroup and an email address - is this good?
Religious discussion about mixing mail and news ensued.
Should use a new header or deal with existing ones and their [broken,
noninteroperable] meanings?
RESOLUTION: more dicussion is necessary on the mailing list.
3. Cancel-Locks
Not much contention here. It appears to be a reasonable draft. People don't want
to implement anything much more complex. Developers present agree that writing
crypto-code is painful.
There were some concerns about the clue-string decreasing security: however, it
sounds like these are all ok with decent implementations.
Using numbers to identify the algorithm is a Bad Thing.
RESOLUTION: the algorithm-number should be replaced by a string.
SUGGESTION: the draft should include examples of generating cancel keys.
SUGGESTION: it would be good to add some weasel words to allow local sites to
cancel articles regardless of cancel locks - we all know that once a site gets an article,
it can do anything it leases to it locally, but we should state this explicitly.
4. Main Draft - Article Format
Consensus is to move authentication into separate, later draft.
There are questions about how much USEFOR should even deal with security issues.
RESOLUTION: move all security, authentication, encryption stuff into a separate,
later draft.
There appear to be IETF problems with S/MIME in drafts. These may be due to time
delays waiting for SMIME to pass IESG.
Mail-News and other Gateway issues need much more work.
ACTION-ITEM: Brian Hernacki will get some text submitted to the WG on this.
The Mail-Copies-To header provoked some discussion. Essentially, the consensus is
that people who want to get mailed copies of responses should ask for them in
[English] as opposed to setting a flag. Copying text should be done by hand/copy
buffers to discourage the quote+"Me Too!" syndrome.
RESOLUTION: it's a UI problem and we should drop it from the standard.
Then we got into the discussion of header classes.
Persistant headers
- People like the concept of persistant headers, but not the idea of a namespace.
RESOLUTION: it's not a class of headers but a characteristic of specific headers.
ACTION-ITEM: Dan Ritter will add "persistent" to definitions section.
Variant headers
- These are items like Path which are modified by transport (and would not be signed).
RESOLUTION: postpone this idea until we find an actual need for it.
Comment headers
- Some folks are opposed to definition because the current practice is different.
Also, it makes transport much harder.
RESOLUTION: Drop the comment class. All such headers will use Xref-style
conventions or else define themselves carefully.
RESOLUTION: Drop requirements for relay-agents to deal with Xref headers.
There's no need.
ACTION-ITEM: Dan Ritter will add definition of comment header to definition
section.
Experimental headers
There appears to be no real gain in using "X-".
- since you have the same odds of namespace collisions
- except automatic detection
- except human recognition.
It's a bad idea because
- transition to real headers is harder.
RESOLUTION: drop it but add a BCP note about passing it in gateways
NOTE: Keith Moore will probably not like this, but he left early so...
In summary: header classes are a theoretical idea, rather than being useful for
implementation. They have all been banished.
Issue: date placeholders [DRAFT-IMPLEMENTATION-DATE, etc.] exist in the
current draft.
Essentially, no one likes flag days.
RESOLUTION: talk to whoever wrote this and find another way to deal with it.
Interoperability takes precedence over convenience.
Finally, we discussed named articles.
There were no supporters for named articles present.
Trying to deal with it will slow WG down further.
It is in the scope of the WG, but not the main document.
RESOLUTION: Brad should write a separate draft for this and submit to the WG.
None received.