Subject: message/news or message/rfc822 (was: draft-ietf-usefor-usefor-09)

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 13:05:34 +0200

Harald Alvestrand wrote:

>>| making all headers compliant with this specification
>>| inherently compliant with [RFC2822].
>> That was "all messages", why a restriction to "all headers" ?
[...]

> actually this is a separation-of-concerns thing; this section
> talks about the headers, the next section talks about the 
> body.
 
> The suggestion I reacted to by suggesting this change was a
> suggestion that if this section talks about messages, it 
> should mention MIME as well as RFC 2822; I thought it better 
> to say that this section (which has "headers" in the title) 
> talks about headers, and leave MIME to the next section.

> It's ticket #1313 if you want to scan the archives.....

I hope that I still recall this without digging.  Section 2.3
and RFC 2049 talk about user agents, user agents must be able
to handle message/rfc822.

After removing it from 2.2 the only place explicitly stating
that the Netnews article format in fact _is_ (a proper subset
of) message/rfc822 is in appendix C (differences from 2822).

Is that good enough for this important point ?  How about 
moving USEPRO-05 5.2 "Message/news obsoleted" as is to USEFOR ?

Admittedly a bit late, but it's more related to USEFOR than to
USEPRO,  A quick scan of section 9 on page 18 in RFC 4288:  No
special problem with declaring message/news as OBSOLETE.  

I wasn't immediately happy with obsoleting message/news, but
others including Henry supported it.  The 4288 template is
(after truncating anything that makes no sense - maybe that
 is not okay, but I don't find the original registration at
 the IANA site, or any other message/foobar registration):

   Type name: message
   Subtype name: news
   Required parameters: none
   Optional parameters: none
   Encoding considerations: 8bit
   Interoperability considerations:
      Many applications support mesage/rfc822, some of
      these applications don't support message/news.
   Security considerations: see RFC xxxx (I-D.ietf-usefor) 
   Published specification: RFC xxxx
   Applications that use this media type: news
   Intended usage: OBSOLETE
   Restrictions on usage: 
      message/news is a proper subset of message/rfc822,
      message/rfc822 should be used instead of message/news
   Author: Henry Spencer
   Change controller: IETF

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Sep 2006 11:05:47 GMT

In <[email-masked]> Ken Murchison <[email-masked]> writes:

>Charles Lindsey wrote:

>> #3. In section 3.2.2 (Archive) there is a new sentence:
>> 
>>    ...  Further discussion of the content of the Archive header
>>    field appears in [I-D.ietf-usefor-useage].
>> 
>> I would have preferred "use" or "application" in place of "content".

>I think I agree, however, a similar sentence is used when discussing 
>Subject.  Should I change that as well?

Actually no. The discussion in USEPRO is mainly concerned with whether the
content of the Subject should include a "Re: ". We had big battles about
that a year or so ago. So the present wording in 3.1.6 is fine.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Sep 2006 05:50:56 -0700

> of) message/rfc822 is in appendix C (differences from 2822).
I think you need to read the document again....

section 2.1 says:

   An article is said to be conformant to this specification if it
   conforms to the format specified in [RFC2822] Section 3 and to the
   additional requirements of this specification.

isn't that clear enough?
>       message/rfc822 should be used instead of message/news
I don't think this can be regarded as a fatal flaw in the specification, 
so I think it's too late to raise this at the resolution-of-comments 
phase of WG Last Call....

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 15:40:08 +0200

> I think you need to read the document again....

Mainly I looked at the diff, top down, and missed...

> section 2.1

...when I saw the change in 2.2.

> isn't that clear enough?

It's perfectly okay, I missed that, sorry.

 [obsoleting message/news]
> I don't think this can be regarded as a fatal flaw in the

Sure, it's only a minor inconsistency, anything related to the
format fits best into USEFOR.  And the interoperability issue
is real, my stoneage UA uses message/news when I forward news.
Other UAs consider this as evil unknown attachment, refusing
to open it.  The best I can do is s/news/rfc822/ manually.

> I think it's too late to raise this at the
> resolution-of-comments phase of WG Last Call....

If nobody disagrees we could add the registry update template
because it's "the right thing", like adding the reference to
3696 because it's mentioned in an ABNF comment.

We have "obsoletes 1036" in the header, that could justify to
also obsolete the MIME type registered with RFC 1036 as its
specification.

If you simply don't want it my premise "if nobody disagrees"
would be wrong (and that point moot).

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Sep 2006 11:17:18 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Please get rid of <msg-id-core> again, it's used nowhere else,
>and it makes that critical part more obscure than necessary.

No, the WG agreed to that change. It is the <msg-id-core> that carries the
semantic meaning, and I may well use it in USEPRO in lots of places where
I currently use "message identifier" (which seems to be the term RFC 2822
uses for the purpose).

>BTW, we might need a usepro-06 draft for the IETF last call.
>Just a maintenance refresh of -05, because that's expired.

See http://www.imc.org/usefor/drafts/draft-ietf-usefor-usepro-05.txt (or
.unpaged). I don't really want to do a new draft of USEPRO just yet. There
are a host of minor things needing attention, and I would like to discuss
the texts relating to Path first.

>Was '"ALL" MUST NOT be used as a <dist-name>' what we wanted ?
>It could be an unnecessary MUST NOT.

It is used by some servers (notably CNews) as a 'wildcard', so there is an
interoperability issue. Some earlier drafts used to say that, but it seems
to have got lost somewhere.

>Is "Once a user agent uses User-Agent" acceptable English ?

Norwegian English apparently :-) . It is good enough.

>Why do we say "SHOULD be ignored" about the obsolete header
>fields, isn't that more like "MUST be ignored" ?  We don't
>want any effects of "Also-Control".

Sufficiently unlikely to happen to warrant a change at this stage. But I
would not object if others want it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 19:17:07 +0200

Charles Lindsey wrote:
 
>> Please get rid of <msg-id-core> again, it's used nowhere
>> else, and it makes that critical part more obscure than
>> necessary.
 
> No, the WG agreed to that change.

Maybe I missed that, and I don't like it, where was that ?
  
> I may well use it in USEPRO

I looked into usepro-05, it's not used there at the moment.
  
> I currently use "message identifier" (which seems to be the
> term RFC 2822 uses for the purpose).

That's fine.  The potential places where "<msg-id-core>" would
be more straight forward than clumsy "<msg-id> without angle
brackets" constructs are rare, "message identifier" is clear.

> http://www.imc.org/usefor/drafts/draft-ietf-usefor-usepro-05.txt

It's not lost, only expired.  Folks reviewing usefor-10 could
misinterpret this.

> I don't really want to do a new draft of USEPRO just yet.

With "maintenance refresh" I meant "new date" and the latest
boilerplate, no serious changes.  If you think that's a waste
of time because no reviewer would dig up the USEPRO reference
then don't submit it again.

>> Was '"ALL" MUST NOT be used as a <dist-name>' what we 
>> wanted ?  It could be an unnecessary MUST NOT.
 
> It is used by some servers (notably CNews) as a 'wildcard',
> so there is an interoperability issue.

Okay, then the MUST NOT is necessary.  If somebody can answer
questions about it in the last call it's okay.

>> We don't want any effects of "Also-Control".
 
> Sufficiently unlikely to happen to warrant a change at this
> stage. But I would not object if others want it.

Okay, one s/SHOULD/MUST/ move waiting for a second or timeout.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Sep 2006 09:52:32 GMT

>special problem with declaring message/news as OBSOLETE.

Various other matters related to new media types and changes to existing
ones are all together in USEPRO. Better to keep it that way.

> the IANA site, or any other message/foobar registration):

It was removed because nobody appeared to be using it. To be useful, it
has to be recognized and processed by user agents (for neat display, etc).
Most user agents currently handle message/rfc822 in a sensible way. How
many agents do the same for message/news? Semantically, the two are
identical.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Sep 2006 09:45:52 GMT

>isn't that clear enough?

Almost. It would be better to move the 2nd sentence of 2.2 (with
s/headers/articles/) to 2.1. If people are happy with this, then it could
be added to Ken's list of niggle fixes. But no big deal, and no reason to
hold things up.

-

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Sep 2006 07:25:55 -0700

> be added to Ken's list of niggle fixes. But no big deal, and no reason to
in that case we'd be saying the same thing twice in one section instead 
of saying it twice in two sections. I fail to see the improvement.

No big deal, but I suggest we let it lie.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 04 Sep 2006 18:52:12 +0200

Charles Lindsey wrote:

> Various other matters related to new media types and changes
> to existing ones are all together in USEPRO. Better to keep
> it that way.

I'm not sure about "better" - if USEPRO takes a quarter of the
time needed for USEFOR it would enter the RFC editor queue in
early 2009.  Maybe 2822 is already obsoleted by some UTF8SMTP
magic at this time.

> It was removed because nobody appeared to be using it.

It's possible that my MUA is the only surviving implementation,
with a worldwide user community of "nobody" (= me),

> Semantically, the two are identical.

Yes, in practice, only the parameter CTE 8bits might differ (?)
In theory it's "will be identical", the "official" news format
is RFC 1036 until USEFOR obsoletes it.

Apparently Henry registered message/news 1993 before s-o-1036,
maybe we could obsolete it informally, a mail from the shepherd
to IANA as soon as USEFOR is approved.

It's okay if you think that that's pedantic and overkill, but I
really like to have all those funny IANA registries up to date,
if it's the dict: URI scheme, or the missing mail format found
by EAI, a lost HTML i18n DTD, or this old message/news entry.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 6 Sep 2006 09:50:45 GMT

>is RFC 1036 until USEFOR obsoletes it.

USEFOR won't obsolete RFC 1036 until it is published as an RFC, which
cannot be before USEPRO is done because of the normative references to
USEPRO within it (even it it is all IESG-approved-and-ready before then).

In any case, it will take USEFOR + USEPRO to obsolete RFC 1036 entirely,
because there is a lot of protocol stuff in RFC 1036.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Sep 2006 04:39:11 -0700

> because there is a lot of protocol stuff in RFC 1036.
Somewhat challenging this statement....

at the moment, and since at least version -00 of -usefor, usepro has 
been listed under INFORMATIVE references. So if the RFC Editor believes 
what we write, he won't block it.

Furthermore, I don't see that the references are of such a nature that 
they would be taken as normative.

The references to USEPRO are:

1.2:

   This is the first in a set of documents that obsolete [RFC1036].
   This document focuses on the syntax and semantics of Netnews
   articles.  [I-D.ietf-usefor-usepro] is also a standards-track
   document and describes the protocol issues of Netnews articles,
   independent of transport protocols such as [I-D.ietf-nntpext-base].
   A best-common-practice document, [I-D.ietf-usefor-useage], describes
   implementation recommendations to improve interoperability and
   usability.

3.1.4:

    <component>s beginning with underline ("_") are reserved for use by
   future versions of this standard and SHOULD NOT be generated by user
   agents (whether in header fields or in newgroup control messages as
   defined by [I-D.ietf-usefor-usepro]).  However, such names MUST be
   accepted by news servers.

   <component>s beginning with "+" and "-" are reserved for private use
   and SHOULD NOT be generated by user agents (whether in header fields
   or in newgroup control messages [I-D.ietf-usefor-usepro]) without a
   private prior agreement to do so.  However, such names MUST be
   accepted by news servers.
....
      NOTE: "example.*" is reserved for examples in this and other
      standards; "poster" has a special meaning in the Followup-To
      header field; "to.*" is reserved for certain point-to-point
      communications in conjunction with the "ihave" control message as
      defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have
      special meanings in some news servers; "all" is used as a wildcard
      in some implementations; and "ctl" was formerly used to indicate a
      <control-command> within the Newsgroups header field.

3.1.5:

   diag-keyword    =  1*ALPHA      ; see [I-D.ietf-usefor-usepro]
...
   A <path-diagnostic> is an item inserted into the Path header field
   for purposes other than to indicate the name of a site.  The use of
   these is described in [I-D.ietf-usefor-usepro].

3.1.6:

   The Subject header field is the same as that specified in Section
   3.6.5 of [RFC2822] with the added restrictions detailed above in
   Section 2.2.  Further discussion of the content of the Subject header
   field appears in [I-D.ietf-usefor-usepro] and
   [I-D.ietf-usefor-useage].

3.2:

   None of the header fields appearing in this section is required to
   appear in every article, but some of them may be required in certain
   types of article.  Further discussion of these requirements appears
   in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

3.2.1:

   The Approved header field indicates the mailing addresses (and
   possibly the full names) of the persons or entities approving the
   article for posting.  Its principal uses are in moderated articles
   and in group control messages; see [I-D.ietf-usefor-usepro].

3.2.3:

   The verb indicates what action should be taken, and the argument(s)
   (if any) supply details.  In some cases, the <body> (as defined in
   [RFC2822]) of the article may also contain details.  The legal verbs
   and respective arguments are discussed in the companion document,
   [I-D.ietf-usefor-usepro].

3.2.12:

   The Supersedes header field contains a message identifier specifying
   an article to be superseded upon the arrival of this one.  An article
   containing a Supersedes header field is equivalent to a "cancel"
   [I-D.ietf-usefor-usepro] control message for the specified article,
   followed immediately by the new article without the Supersedes header
   field.

5:

   Further security considerations are discussed in
   [I-D.ietf-usefor-usepro].

We have talked before about the need to hold back USEFOR in case we 
discover the need to make changes in USEFOR while we are sorting through 
the details of USEPRO. But I don't see that it's obvious that it's a 
true normative dependency.

If someone wishes to argue that it is, please state:

- Which of the references above you see as "normative"
- That you think the USEPRO reference needs to be moved from the 
"informative" to the "normative" section.

The moving is a quick edit. But I'm not certain we need to do it.

                         Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 7 Sep 2006 19:18:55 GMT

>what we write, he won't block it.

Hmmm! I had not noticed that. However, I agree that USEFOR does not depend
normatively on USEPRO, although USEPRO will certainly depend normatively
on USEFOR. However, USEFOR on its own does not tell you how to construct a
Netnews system (any more than RFC 2822 tells you how to construct an email
system).

OTOH, I understood you to say, at the time of your first last call some
months back, that USEFOR, even if it passed IETF Last Call now, would not
actually be published until USEPRO caught up with it.

>   implementation recommendations to improve interoperability and

Actually, that paragraph makes exactly the point I was trying to raise. It
states that, in order to obsolete [RFC1036], a "set of documents" will be
needed, and then lists USEPRO and USEAGE as the other two. I grant you
that USEAGE is not really necessary for the purpose, and indeed had noted
that slight anomaly some time ago, but did not think it important enough
to quibble about. But certainly, USEFOR on its own, does not address all
the matters that RFC1036 deals with.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Sep 2006 00:07:06 -0700

> actually be published until USEPRO caught up with it.
That was said, yes. I think that's a reasonable idea.

However, if the group peters out totally before publishing USEPRO, it 
may actually be rational for the IESG to say "OK, let's just push USEFOR 
as an RFC".
> the matters that RFC1036 deals with.
Agreed.