Subject: I-D Action:draft-ietf-usefor-usepro-11.txt

From: [email-masked]
Date: Fri, 22 Aug 2008 15:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title           : Netnews Architecture and Protocols
	Author(s)       : R. Allbery, C. Lindsey
	Filename        : draft-ietf-usefor-usepro-11.txt
	Pages           : 51
	Date            : 2008-08-22

This document defines the architecture of Netnews systems and
specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and
displays them.  It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles.Internet
Draft Comments

Comments are solicited and should be addressed to the Usenet Format
Working Group at [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 23 Aug 2008 19:13:28 +0200

> Filename        : draft-ietf-usefor-usepro-11.txt
[...]
> Comments are solicited and should be addressed to
> the Usenet Format Working Group at [email-masked].

New tools trick, you can extract the ABNF as seen by 
http://tools.ietf.org/abnf/draft-ietf-usefor-usepro-11

Skipping two lines which are no ABNF I copied the
output and pasted it "as is" in Bill's ABNF parser.

| 11: moderation-flag     = SP "(" %4D.6F.64.65.72.61.74.65.64 ")"
|                                  ^
| 11:30: error: Illegal character '%' - skipping to end of line

ITYM %x, I manually fixed the input to check the effect.

| 17: control-command     =/ Newgroup-command
| 18: Newgroup-command    = "newgroup" Newgroup-arguments
|   ^
| 18:0: error: Rule control-command does not yet exist; treating /= as =

I manually added an "import" rule at the top like this:

: control-command  = <see [USEFOR] section 3.2.3>

After that it was at "no errors" listimg all undefined
and unused terms.  Bill's "canonical format" is a matter
of taste, but always intersting to see:

| ; CRLF UNDEFINED
| ; SP UNDEFINED
| ; newsgroup-name UNDEFINED

That's IMO no okay.  Please import it:

: newsgroup-name        = <see [USEFOR] section 3.1.4>

| ; HTAB UNDEFINED
| ; newsgroup-description UNDEFINED

That's an artefact of the ABNF extraction tool, I copied
the missing term manually to the ABNF input form field:

: newsgroup-description
:                     = eightbit-utext *( *WSP eightbit-utext )

| ; WSP UNDEFINED
| ; utext UNDEFINED

That's a real issue in the draft.  ITYM that it MUST be
<UTF8-non-ascii> as specified in RFC 3977, but servers
MUST in practice accept any octet.  How about this:

- eightbit-utext      = utext / %d127-255
+ eightbit-utext      = UTF8-non-ascii / %d128-255
+ UTF8-non-ascii      = <see RFC3977 section 9.8>
+
+ Note that <eightbit-utext> MUST be <UTF8-non-ascii>,
+ but for backwards compatibility servers MUST other
+ non-ASCII octets.

Technical detail, I omitted %d127 (DEL), because it is
not obviously needed.  Please spice it with a RFC 5198
reference to get NFC.  The EAI drafts do this, it is no
new untested idea.  BTW, they also use <UTF8-non-ascii>.

Back to the ABNF parser output:

| ; DIGIT UNDEFINED
| ; msg-id UNDEFINED

That is critical, various different definitions exist.
Please import the (here) relevant <msg-id> definition:

: msg-id                = <see [USEFOR] section 3.1.3>

Not RFC 3977 without "@", not RFC 2822 with NO-WS-CTL,
not RFC 2822upd allowing ">" (IIRC), and not RFC 1036.

It is a zoo, and for this round I hope to arrive at a
consistent story.  To align this with 2822upd I think
that a later RFC.ietf-usefor-usefor update would cover
all cages in the NetNews department of this zoo (down
to the news: URIs).

| ; path-identity UNDEFINED

: path-identity          = <see [USEFOR] section 3.1.5>

| ; control-command defined but not used
| ; groupinfo-body defined but not used
| ; checkgroups-body defined but not used
| ; sendme-body defined but not used

That's as it should be.  When you add the imported terms
you could also import the used STD 68 terms, as we did
it in RFC.ietf-usefor-usefor

Subtle point, instead of "[USEFOR]" please use "RFCnnnn"
in ABNF prose definitions, and add an RFC-editor note to
replace "yyyy" by the RFC number.

The very popular "rfcmarkup" tool can identify "RFCnnnn
section X.Y" as link to a section X.Y in RFCnnnn.  We're
not supposed to cuddle simple-minded tools in RFCs, but
in that case I think it is worth it, rfcmarkup-format is
used in RFC links by almost all MediaWiki installations.

You use a few ABNG terms like <verb> in the prose.  When
you add an "ABNF import interface" in chapter 1 please
import also those terms while you are at it.  IMHO this
helps to read (and maybe understand) non-trivial memos.

--------------------------------------------------------
Related nits:  Please upgrade RFC 4234 to 5234 (STD 68).
The USEAGE reference should get a proper URL.  I found
a trick to bypass the xml2rfc "work in progress" blurb:

<reference
  anchor='USEAGE'
  target='http://tools.ietf.org/html/draft-ietf-usefor-useage-01'>
  <front>
    <title>Usenet Best Practice</title>
    <author initials='C.' surname='Lindsey'
            fullname='Charles H. Lindsey'>
      <organization>University of Manchester</organization>
    </author>
    <date month='March' year='2005' />
  </front>
  <seriesInfo name='Internet' value='draft-ietf-usefor-useage-01' />
  <format type='TXT'
    target='http://tools.ietf.org/id/draft-ietf-usefor-useage-01' />
</reference>

The trick in this reference is <seriesInfo name="Internet" ...
(Tested in the news: URI RFC for the historical Gilman draft.)

Maybe add an RFC editor note that "2822" instead of "2822upd"
is as it should be for reasons they don't need to care about
unless they are willing to read the complete USEFOR archive
as prerequisite for real explanations.

I'm surprised that you got away without a s-o-1036 reference,
but I'm not going to investigate how you pulled that stunt.

If it was only the lack of a ready made xml2rfc <reference>
check out the news: URI I-D xml source under .../home/test

------------------------------------------------------------
IANA business

Last sentence in the intro of chapter 4, please add an exact
reference to [RFC2046] section 5.2.1.  After EAI introduced
a new message/global these details matter.   Not being exact
could require an essay in the security considerations, but
we have no time for this potential fun.

Please post review requests for application/news-checkgroups,
application/news-transmission, and application/news-groupinfo
on the types review list.

If you already did that years ago I missed it, but I guess
we simply forgot to do this.  It is mostly "pro forma", but
sometimes the experts ask good questions resulting in fixed
registration templates.

Clearly I should post the review requests, because I think
they are required.  But I could not answer questions about
many application/news-* details.  AFAICT Harald is also in
the "required" camp.

For message/news I think you *could* add a new registration
template, because you modify not only the status, but also
the semantics ("use message/rfc822"), and the owner (IETF).

But maybe that is irrelevant and/or too late now.  If not:

: MIME type name:           message
: MIME subtype name:        news
: Required parameters:      none
: Optional parameters:      charset, compare message/rfc822
: Disposition:              by default, inline
: Encoding considerations:  compare message/rfc822 (RFC 2046)
: Security considerations:  OBSOLETE, use message/rfc822.
: Interoperability considerations:
:                           Rarely used; and therefore often
:                           handled as application/octet-stream
: Published specification:  son-of-1036, RFCXXXX
: Applications that use this media type:
:                           Some old mail and news user agents
: Intended usage:           OBSOLETE
: Author:                   Henry Spencer 
: Change controller:        IETF

Looking in RFC 4288 I found that you did not use some fields
in the other templates.  I can't tell if that is okay, e.g.,
IMO "change controller: IETF" is implied by standards track.

That's the point where you might need a proper [son-of-1036]
reference, grab it from one of the XML sources.  I think you
should not say "this specification" in any IANA template, 
they are supposed to store these templates on their server.

(What they do in practice is a diferent question, I did not
 find the old original message/news template spontaneously).

You can use the magic &rfc.number; in xml2rfc sources for
this purpose.  It expands to RFCXXXX in drafts, and to the
RFC number in AUTH48.  (Hopefully, I can't test this theory
before RFC.ietf-usefor-usefor RFC got its number.)

BTW, where did you find "Disposition" in RFC 4288 ?  It is
a good idea, but maybe it belongs to the "Interoperability".

 Frank

---

From: Russ Allbery <[email-masked]>
Date: Sat, 23 Aug 2008 11:47:18 -0700

> ITYM %x, I manually fixed the input to check the effect.

Thanks, fixed.

> That's IMO no okay.  Please import it:

The ABNF in USEPRO is additive to the ABNF in USEFOR and the Core Rules
defined in RFC5234 as noted in 1.4.

> MUST in practice accept any octet.

No, I mean what the text says.

   While a charset parameter is defined for this media type, most
   existing software does not understand MIME header fields or correctly
   handle descriptions in a variety of charsets.  Using a charset of US-
   ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8
   [RFC3629] SHOULD be used.  Regardless of the charset used, the
   constraints of the above grammar MUST be met and the <newsgroup-name>
   MUST be represented in that charset using the same octets as would be
   used with a charset of US-ASCII.

> How about this:

You'll have to convince the chairs to reopen this topic if you want to
make a change to the specification in this area, since that's not the
policy that we previously reached consensus on for how to handle Unicode.

> new untested idea.  BTW, they also use <UTF8-non-ascii>.

Likewise here.  I don't care one way or the other about DEL, but making
substantive changes at this phase is just asking for trouble.  I'm willing
to drop it if there's clear consensus and the chair okays making that
change, but not otherwise, since we're trying to finish.

> : msg-id                = <see [USEFOR] section 3.1.3>

I don't think it's necessary to note everywhere that we reference msg-id
that we mean the version defined in USEFOR.  I think the introduction to
the document covers that adequately.

> used in RFC links by almost all MediaWiki installations.

I don't think this is useful.  [USEFOR] is a much simpler search string to
use to find all instances that need to be corrected once the other draft
has been published.

> You use a few ABNG terms like <verb> in the prose.  When you add an
> "ABNF import interface" in chapter 1 please import also those terms
> while you are at it.

I don't, at present, intend to add an import interface.

> Related nits:  Please upgrade RFC 4234 to 5234 (STD 68).

Done.

> The USEAGE reference should get a proper URL.

Done, thanks.

> I found a trick to bypass the xml2rfc "work in progress" blurb:

They should have a work in progress blurb.  They're Internet-Drafts.  I
missed the <seriesInfo> tag here and for USEFOR; fixed.

The status of USEAGE needs to be resolved before publishing the document.
If it's not going to be published, we need to strip all references to
USEAGE in this document.  So having the work in progress tag is useful to
be sure that we do that.

> as prerequisite for real explanations.

I didn't think that 2822upd breaks anything that wasn't already broken.
What are you worried about having break here?

> reference to [RFC2046] section 5.2.1.

Done.

> many application/news-* details.  AFAICT Harald is also in

I don't have time to do this at present and can make no promises as to
when I will have time to do so.

> But maybe that is irrelevant and/or too late now.

I'm inclined not to bother with this unless people feel it would be
worthwhile.  It makes the draft longer and I don't think anyone's going to
care.

> IMO "change controller: IETF" is implied by standards track.

Yeah, I don't know if this is okay or not either.  I can do whatever the
right thing to do here is.  Should I add all of the other template
attributes there?

> a good idea, but maybe it belongs to the "Interoperability".

I didn't; I just didn't change it.  This has been in the draft for quite a
while.  Should I remove it?  I don't see Disposition anywhere in the media
type registration either.

> before RFC.ietf-usefor-usefor RFC got its number.)

Thank you.  Charles had this right and I broke it; I'm now using
&rfc.number;, which seems like a good solution.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 23 Aug 2008 23:43:29 +0200

Russ Allbery wrote:

> The ABNF in USEPRO is additive to the ABNF in USEFOR and the
> Core Rules defined in RFC5234 as noted in 1.4.

Tools like the ABNF extractor don't know this, I think it's a
good idea to have an "import interface" also for human users.

The <control-command> continuation based on a start in USEFOR
is not obvious for folks not familiar with the details.  As
in say "IESG members, GenArt reviewers, or RFC-editor staff",
who might all try to check the ABNF "as is".  

I did *not* check what happens if the USEFOR + USEPRO syntax
is simply aggregated, maybe that is good enough.

 [utext]
[...]

I looked only at the ABNF, references, and stuff related to
the IANA templates.  SHOULD ASCII and otherwise SHOULD UTF-8
makes sense.  Checking the <utext> again I think you are not
talking about some "Unicode text", but about "unstructured
text" <utext> in RFC 2822 imported via RFC.ietf-usefor-usefor:

| utext   =       NO-WS-CTL /     ; Non white space controls
|                  %d33-126 /     ; The rest of US-ASCII
|                 obs-utext

Or actually about the non-obsolete part of RFC 2822 <utext>.

>From my POV that's not intuitive, especially because 2822upd
has no <utext> at all.  I propose to spell out what you want
here, in essence any MIME-compatible octet, that is not NUL,
and lots of fine print for CR LF.  You could simply write:

:  eightbit-utext = %d1-9 / %d11-12 / %d14-255

The name "eightbit-utext" is arguably confusing, at least it
managed to confuse me.  Please use <eightbit-mime> for this,
it would also reflect the "NOTE" at the begin of chapter 2.

>| Regardless of the charset used, the constraints of the
>| above grammar MUST be met and the <newsgroup-name> MUST
>| be represented in that charset using the same octets as
>| would be used with a charset of US-ASCII.

I don't understand the last part "using the same octets as
would be used with a charset of US-ASCII".  What does this
mean ?  

Let's say the newsgroup-name is example.öko with an umlauted
o.  There are many ways to limit this to ASCII, oe, &ouml;,
percent-encoded UTF-8, numeric character references (NCRs,
i.e. Unicode points), IDNA punycode (but that won't fly for
some non-LDH ASCII group characters), RFC 2047, and more.  

>> Technical detail, I omitted %d127 (DEL), because it is not
>> obviously needed.  Please spice it with a RFC 5198
>> reference
[...]
 
> Likewise here.  I don't care one way or the other about DEL,
> but making substantive changes at this phase is just asking
> for trouble.  I'm willing to drop it if there's clear 
> consensus and the chair okays making that change, but not
> otherwise, since we're trying to finish.

FWIW all but one %d127 uses in 2821bis drafts were removed.
We are quibbling about a non-issue, I didn't understand what
<utext> is.  See above for a better name and clearer syntax.

> I don't think it's necessary to note everywhere that we
> reference msg-id that we mean the version defined in USEFOR.

Agreed, I also don't think that it is necessary to note this
fact *everywhere*.  I proposed to note this *once* in syntax,
in an "import interface".  In prose you have it already, but
I didn't look at your prose for my ABNF validation.

> [USEFOR] is a much simpler search string to use to find all
> instances that need to be corrected once the other draft has
> been published.

I thought that you intend to keep [USEFOR] and [USEAGE] in the
prose.  If that's not the case forget my idea - it makes only
sense when you'd update [USEFOR] or rather RFCnnnn only in the
syntax, keeping [USEFOR] elsewhere as is.

Just in case, the drafts will be published simultaneously, they
have bidirectional normative references.

  [<verb> e.a.]
>> When you add an "ABNF import interface" in chapter 1 please
>> import also those terms while you are at it.
 
> I don't, at present, intend to add an import interface.

I recently added an import interface to a draft that needs no
syntax at all.  After that I finally began to understand what
this draft is about (= the other "u", not as in <utext>, but
as in U-label).

> The status of USEAGE needs to be resolved before publishing

The WG will be terminated, and the USEAGE reference is only
informative...  

> If it's not going to be published, we need to strip all 
> references to USEAGE in this document.

...not required, and USEAGE won't be published anytime soon.

IMO nothing is wrong with an informative reference to prior
related work.  But saying that it's "work in progress" when
that's not the case (at the moment) could be bad.  The folks
at rfc-editor.org could decide to treat USEAGE as MISSREF...

[Actually I think they can't simply decide this, and that's
 the core idea of "normative" vs. "informative" references.]

> I didn't think that 2822upd breaks anything that wasn't 
> already broken. What are you worried about having break
> here?

The <utext> detail is interesting.  NO-WS-CTL was firmly
moved to "obs-cene".  IIRC no more <dcontent> (that was a
nit in 2821bis, no nit in usepro).  Various minor fixes
related to old 822 #-lists (all "obs" => irrelevant here).

 [review requests]
> I don't have time to do this at present and can make no
> promises as to when I will have time to do so.

Okay, sometimes the WG Chairs or the responsible AD do this
for WG drafts.  But doing it too late is sub-optimal, after
all a review request *could* trigger a no-nonsense review.

 [message/news template]
> I'm inclined not to bother with this unless people feel it
> would be worthwhile.  It makes the draft longer and I don't
> think anyone's going to care.

Clearly I think it is worthwhile, because IANA cannot do much
to "obsolete" message/news without a template.  All they can
do without template is update their 1036 reference to USEPRO.

But it might be possible to submit the template individually,
should I try this ?  In that case I'd be at least confident 
about posting a review request "on behalf of the USEFOR WG",
e.g. I'd know that I can't say "on behalf of".

> I didn't; I just didn't change it.  This has been in the
> draft for quite a while.  Should I remove it?  I don't see
> Disposition anywhere in the media type registration either.

You could add an "Interoperability considerations" field, and
put the "default disposition inline" into this field.  Maybe
Charles still knows where he found this ?  (= not in RFC 4288)

For "message/news" I'd remove it as not more relevant if we
pick the "make it so" out-sourced IANA registration approach.

 Frank

---

From: Russ Allbery <[email-masked]>
Date: Sat, 23 Aug 2008 15:16:01 -0700

> good idea to have an "import interface" also for human users.

I'm sympathetic that this might be interesting in general for the IETF,
but in the absence of a general IETF policy or some standard about how
this is supposed to be done, I think this is just about the worst possible
working group to be innovating in how we present ABNF.  What we're doing
right now seems to be pretty much in line with what other RFCs are doing,
although I may have missed recent changes.

Is there something like that available, such as documentation of the
import syntax that you're using, in an RFC or a guideline for ABNF usage
somewhere?

> Or actually about the non-obsolete part of RFC 2822 <utext>.

I'm sorry to be uninformative here, but the points you are raising are
points previously discussed in the working group on an issue that was
closed.  In the interests of trying to shut this down, I'm going to
decline to discuss this issue unless the chairs determine that it should
be reopened.

> syntax, keeping [USEFOR] elsewhere as is.

Ah, yes, the [USEFOR] string will definitely change.  [USEAGE] is, from my
perspective, rather up in the air.

> at rfc-editor.org could decide to treat USEAGE as MISSREF...

There are only two references to USEAGE in the document (3.8 and 3.9).
Personally, I think they're expendible.  If USEAGE isn't going to be
published, I think the best resolution is to just remove them.  I'd rather
not cite an I-D in a published RFC, and I suspect the RFC Editor would
have similar qualms.

> all a review request *could* trigger a no-nonsense review.

I think it's definitely a good thing to do.  I just won't be able to do it
soon.  I might be able to do it towards the end of September; failing
that, I won't have a free block of time until November.  Unless there's
likely to be no discussion other than just the message, which of course is
simple, but usually that's not true of public IETF review.

> do without template is update their 1036 reference to USEPRO.

That's a good point.

> e.g. I'd know that I can't say "on behalf of".

I'm very happy to either support that.  I can also include the template in
the document easily enough if the working group thinks that's the right
thing to do.  Does anyone else have an opinion?

> Charles still knows where he found this ?  (= not in RFC 4288)

Charles, do you remember?

> pick the "make it so" out-sourced IANA registration approach.

I think it's worthwhile to explicitly deprecate it in the text of a
published RFC, personally, but maybe I'm too anal about that.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 04:58:42 +0200

Russ Allbery wrote:
 
> I'm sympathetic that this might be interesting in general
> for the IETF, but in the absence of a general IETF policy
> or some standard about how this is supposed to be done, I
> think this is just about the worst possible working group
> to be innovating in how we present ABNF.

The "prose ABNF" was not invented here, it is pure STD 68.
Maybe this WG invented the idea of using "prose ABNF" for
ABNF imports, but IIRC Bill Fenner had the idea before us.

BTW, this WG was the first to adopt the RFC 3696 <toplabel>
concept in a standards track RFC.  IMO that was innovative,
the rest of the IETF still uses RFC 1123 2.1 (officially).

Harald even asked IAB and ICANN what they think about this
innovation.  RFC.usefor supported IDNA TLDs *before* ICANN,
one of those procedural stunts I love.  

> Is there something like that available, such as
> documentation of the import syntax that you're using, in
> an RFC or a guideline for ABNF usage somewhere?

STD 68.  You can simply test it with Bill's ABNF validator:

| No errors during parsing.
[...]
| foo = <as specified in RFC 3092>
| bar = foo [ foo ]
| ; bar defined but not used

 [Expand <utext> because it's not defined in 2822upd]
> I'm going to decline to discuss this issue unless the
> chairs determine that it should be reopened.

My proposed <utext> expansion was wrong, it included WSP.
The "real thing" (adding 8bit, but removing obs- and WSP):

eightbit-utext = %d1-8 / %d11-12 / %d14-31 / %d33-255

<eightbit-utext> is used in exactly one production:

newsgroup-description = eightbit-utext *( *WSP eightbit-utext )

Renaming it to <eightbit-mime> is a matter of taste.  But
using the term <utext> after it was removed from 2822upd,
and while it contains NO-WS-CTL declared to be obsolete in
2822upd, is IMO a seriously confusing idea.

Whatever the WG decided in 2007, the 2822upd modifications
wrt <utext> and NO-WS-CTL are new (2008) events, based on
feedback from Charles, you, and me (among others) on the
rfc822 list.

Nobody here could foresee that there will be no <utext> in
2822upd before the author pulled it.  Technically this is
no problem, because you reference 2822, not 2822upd.  But
my confidence that readers can figure this detail out is
limited.  I changed the subject to attract the attention
of Harald and Alexey. 

> I'd rather not cite an I-D in a published RFC, and I
> suspect the RFC Editor would have similar qualms.

Dunno - if they'd ask me to remove s-o-1036 or the Gilman
draft references I won't comply.  But that is a different
case, these drafts are very obviously "historic" (and no
IETF WG drafts).

 [message/news] 
> I'm very happy to either support that.  I can also include
> the template in the document easily enough if the working
> group thinks that's the right thing to do.  Does anyone
> else have an opinion?

Okay, in both cases the template needs a review request, I'm
going to post that as proposed earlier...  One of four down.

> I think it's worthwhile to explicitly deprecate it in the
> text of a published RFC, personally, but maybe I'm too
> anal about that.

Sure.  Your "out-sourcing" idea was about the template, not
the place of the deprecation (= as is, RFCXXXX).  You said
the template is too long... <shrug />  

Maybe note the timestamp (today) of this review request in
the document history - I try to note all relevant facts for
a later writeup in the document history (so far for anal ;-) 

 Frank
-- 
<http://article.gmane.org/gmane.ietf.types/1080>

---

From: Russ Allbery <[email-masked]>
Date: Sat, 23 Aug 2008 20:15:16 -0700

> ABNF imports, but IIRC Bill Fenner had the idea before us.

Oh, I see my mistake.  I thought the : that you were putting on those
lines was part of your suggested syntax, but you're just using it as a
quoting character.  I couldn't find that syntax in STD 68.

I'm sorry about that; that was my confusion.

So you think that we should put somewhere a list of all the ABNF labels
that we use from other documents into the introduction, probably in the
Syntax section.  Hm.  Well, since you've already tracked most of them
down, I think I'm not adverse, and mechanical validation of ABNF is
definitely useful.

Would you be willing to prepare a patch?  That would be even faster for
me.

>> I'd rather not cite an I-D in a published RFC, and I suspect the RFC
>> Editor would have similar qualms.

> Dunno - if they'd ask me to remove s-o-1036 or the Gilman draft
> references I won't comply.  But that is a different case, these drafts
> are very obviously "historic" (and no IETF WG drafts).

Yes, Son-of is something of a special case.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 06:37:16 +0200

Russ Allbery wrote:

> since you've already tracked most of them down, I think I'm not
> adverse, and mechanical validation of ABNF is definitely useful.
 
> Would you be willing to prepare a patch?  That would be even
> faster for me.

I have no patch tool yet on the W2K box, but I can prepare an XML
snippet for copy and paste, you can insert it where it fits.

Style counter, you start in column 10 with the "=" in column 30:
         newsgroups-line     = newsgroup-name
....5...10....5...20....5...30....5...40....5...50....5...60....5...70..
~~~ cut ~~~
<figure><artwork type="abnf"><![CDATA[
         CRLF                = <see RFC 5234 appendix B.1>
         DIGIT               = <see RFC 5234 appendix B.1> 
         HTAB                = <see RFC 5234 appendix B.1>
         SP                  = <see RFC 5234 appendix B.1>
         WSP                 = <see RFC 5234 appendix B.1>

         argument            = <see [USEFOR] section 3.2.3>
         article-locator     = <see [USEFOR] section 3.2.14> 
         component           = <see [USEFOR] section 3.1.4>
         control-command     = <see [USEFOR] section 3.2.3>
         diag-keyword        = <see [USEFOR] section 3.1.5>
         diag-match          = <see [USEFOR] section 3.1.5>
         diag-other          = <see [USEFOR] section 3.1.5> 
         dist-name           = <see [USEFOR] section 3.2.4>
         msg-id              = <see [USEFOR] section 3.1.3>
         newsgroup-name      = <see [USEFOR] section 3.1.4>
         path-delimiter      = <see [USEFOR] **KERNEL PANIC**>
         path-diagnostic     = <see [USEFOR] section 3.1.5>
         path-identity       = <see [USEFOR] section 3.1.5>
         path-nodot          = <see [USEFOR] section 3.1.5>
         tail-entry          = <see [USEFOR] section 3.1.5> 
         verb                = <see [USEFOR] section 3.2.3>

         display-name        = <see RFC 2822 section 3.4>
         local-part          = <see RFC 2822 section 3.4.1>
         mailbox             = <see RFC 2822 section 3.4>
         utext               = <see RFC 2822 section 3.2.6>
]]></artwork></figure>
~~~ end ~~~

Strike <path-delimiter>, both memos use this only in prose. 

BTW, if you are annoyed how xml2rfc splits some ABNF terms
in prose at the hyphen write &nbhy; (= no break hyphen).

Integration test, I grab this stuff and paste it in the
still open ABNF parser form, result:  No errors, good.

You'll get more than four allegedly unused ABNF terms now,
because I added all terms in angle-brackets in the prose.
But that's as it should be, ignore it.

 Frank

---

From: Russ Allbery <[email-masked]>
Date: Sat, 23 Aug 2008 22:54:03 -0700

> snippet for copy and paste, you can insert it where it fits.

This is perfect -- thank you very much!  I'll incorporate this probably
tomorrow.  Apologies for the misunderstanding originally, and thank you
for talking me through it.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 24 Aug 2008 07:04:53 -0700

> The WG will be terminated, and the USEAGE reference is only

Agreed.

> ...not required, and USEAGE won't be published anytime soon.

Indeed. An informative reference is not going to block publication of
the document.

> related work.

IMHO, it is much better having such references in documents. This make
it much easier for people to find history of the document or related
documents. And if one google for the USEAGE document, one would find
the document long after it expires.

> But saying that it's "work in progress" when
> that's not the case (at the moment) could be bad.

An Internet draft has limited lifetime (6 months), so saying that is
is work in progress is appropriate (i.e. the work is not finished and
the document is not an RFC).

> The folks at rfc-editor.org could decide to treat USEAGE as MISSREF...

No, they wouldn't, unless you explicitly ask them to delay publication
till the informative reference is published as an RFC. They publish
RFCs with informative references to drafts all the time.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 24 Aug 2008 07:08:48 -0700

> not cite an I-D in a published RFC, and I suspect the RFC Editor would

See my reply to Frank's message.

> I think it's definitely a good thing to do.

I think it is not only a good idea, but it is also a require step.

>  I just won't be able to do it
> I'm very happy to either support that.

Frank, speaking as a chair I am happy for you to submit the review
request on behalf of the WG.

> I can also include the template in

I think that is the right thing to do.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 24 Aug 2008 19:36:58 +0200

Alexey Melnikov wrote:

> I am happy for you to submit the review request
> on behalf of the WG.

Done for message/news, where I know the background.

For the application/news-* registrations it's better
when they're first fixed, and when somebody posts a
review request who could answer questions about the
application/news-* details.  

>> I can also include the template in the document
>> easily enough if the working group thinks that's
>> the right thing to do.  Does anyone else have an
>> opinion?
 
> I think that is the right thing to do.

+1   Of course it makes the text longer, but 4 or 3
templates is no big difference (less than one page).

 Frank

---

From: Russ Allbery <[email-masked]>
Date: Sun, 24 Aug 2008 21:17:57 -0700

"Alexey Melnikov" <[email-masked]> writes:

>> published, I think the best resolution is to just remove them.  I'd
>> rather not cite an I-D in a published RFC, and I suspect the RFC Editor
>> would have similar qualms.

> See my reply to Frank's message.

Okay, I can leave it in.

>> I can also include the template in the document easily enough if the
>> working group thinks that's the right thing to do.  Does anyone else
>> have an opinion?

> I think that is the right thing to do.

Now included.

I should probably upload another draft, but I'll give it a day or two for
people to turn up any additional concerns that should be addressed in the
next draft.  I will put out another version by the 28th, after which I
will be unavailable to do working-group work for a week or two.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Aug 2008 13:12:31 GMT

>will be unavailable to do working-group work for a week or two.

I am sure that there will be lots of niggles once people get a chance to
read the latest draft (it is a long time since we had an up-to-date
complete draft to consider as a whole). So, rather than rushing to produce
instant drafts every couple of daye, I would suggest planning on doing it
when your "week or two" is over.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Aug 2008 12:03:21 GMT

>Charles, do you remember?

The reason it is there is that these are application MIME types, and as
such are normally expected to be processed by the receiving agent in some
application-specific manner (as indeed these are, for inserting
information into the local Newsgroups file). However, they are also
intended to be human readable (as indeed they are at present, since they
are currently not MIME types at all, and we have cunningly designed the
format so as to fool current software into recognising them). Moreover,
in the absence of a Content-Dispostion header, RFC 2183 is silent on
whether the default is "inline" or not; so we really need to say
something.

I "invented" the "Disposition" line in the template because it seemed like
a good way to do it. However, on readng RFC 4288, I now think it would be
better to include it under an "Additional Information" line in the
template, since section 4.11 of that RFC seems to imply that you can put
anything sensible in there. The change could easily be made.

I also note that there is a "Restriction on usage" header in the RFC 4288
template, and it might be useful to say that news-groupinfo and
news-checkgroups were only for use in newsgroup control messages (in which
case the "Intended usage" header should say "LINITED USE").

Note that none of these exotic headers existed in RFC 2048, which was the
relevant standard at the time I first wrote these templates.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Aug 2008 13:09:16 GMT

>feedback from Charles, you, and me (among others) on the

Yes, we managed to get more changed in RFC 2822-bis than we could ever
have expected.

>limited.  I changed the subject to attract the attention

I still think that, now 2822bis has been accepted by the IETF and will
presumably become a Draft Standard, we should revisit USEFOR and rebase it
on 2822-bis (firmly resiting all temptations to make any technical
changes). It should be quite straightforward, and if Ken is not
able/willing to do it, then I will volunteer. Ken?

---

From: Russ Allbery <[email-masked]>
Date: Mon, 25 Aug 2008 10:59:20 -0700

"Charles Lindsey" <[email-masked]> writes:

> complete draft to consider as a whole). So, rather than rushing to
> produce instant drafts every couple of daye, I would suggest planning on
> doing it when your "week or two" is over.

I'd rather upload another draft before the AD deadline, just because.  I
probably won't continue to try to keep to that sort of quick upload
schedule after that.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 25 Aug 2008 11:01:21 -0700

"Charles Lindsey" <[email-masked]> writes:

> I "invented" the "Disposition" line in the template because it seemed
> like a good way to do it. However, on readng RFC 4288, I now think it
> would be better to include it under an "Additional Information" line in
> the template, since section 4.11 of that RFC seems to imply that you can
> put anything sensible in there. The change could easily be made.

I stuck it into Implementation considerations, which seemed even more
appropriate, but I can move it if people think that would be better.

> I also note that there is a "Restriction on usage" header in the RFC
> 4288 template, and it might be useful to say that news-groupinfo and
> news-checkgroups were only for use in newsgroup control messages (in
> which case the "Intended usage" header should say "LINITED USE").

I don't see a need to limit either to newsgroup control messages.  They're
both useful outside of that context (news-checkgroups more so,
admittedly).  However, I don't feel strongly about news-groupinfo; if
people think it's sufficiently weird that it doesn't make any sense to use
it outside of control messages, I'm willing to make that change.  I feel
more strongly that news-checkgroups is appropriate in a much wider variety
of situations.

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 25 Aug 2008 22:59:12 +0200

Charles Lindsey wrote:

> I would suggest planning on doing it when your
> "week or two" is over.

Lisa's deadline is 08-29, and Russ' 08-28 fits.
Integers for draft numbers are a cheap resource:

The years old "usepro" has the same number of 
versions as the weeks old "idn-tlds" (2606bis).

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 25 Aug 2008 23:56:18 +0200

Charles Lindsey wrote:

>> based on feedback from Charles, you, and me (among others)
>> on the rfc822 list.
 
> Yes, we managed to get more changed in RFC 2822-bis than we
> could ever have expected.

The author successfully avoided the simple approach to adopt 
our prior work wholesale.  His new <msg-id> (minus obs) is
now simpler than our form, but allows ">".

His <msg-id> plus obs is of course unacceptable for NetNews.
All pieces are in place for a *future* final merger, but not
for a sudden rush of AUTH48 modifications.  

Harald already said that he has no energy to coordinate that.
Lisa also never committed to general 2822upd upgrades of the
NetNews RFCs.  And any last minute screwing with fundamental
concepts such as <msg-id-core> would deserve new Last Calls.

Leave this alone for this round.  Start the screwing in 2009
if you must.  Folks in the real world outside of USEFOR still
are forced to use RFC 1036 in their references (example, the
Archived-At standard).

The top priority is to get this stuff out now after 10 years,
not to start another round of <msg-id-core> embellishments.

Or to fix <toplabel> after the RFC 3696 author changed his
mind to "LDH starting with L".  (Foreseeable getting nothing,
his 1123-erratum killed my erratum, and the two DNSEXT folks
supposed to fix RFC 1123 in two lines went AWOL immediately
after volunteering for this job).

Or whatever else could be done in the approved RFCs above a
harmless AUTH48 fix of s/<path-delimiter>/path delimiter/ -
the <utext> problem of course also affects USEFOR, not only
USEPRO.

> I still think that, now 2822bis has been accepted by the
> IETF and will presumably become a Draft Standard, we should
> revisit USEFOR and rebase it on 2822-bis

NAK.  This is not "straight forward".  There are lots of at
first glance minor differences between 2822 and 2822upd with
subtle consequences for the NetNews RFCs.  And we even know
that 2822upd can't be the last word:  

It has a "white space in quoted string local parts" concept
incompatible with 2821bis (found by Alexey, IIRC).  But for
this round nobody had the energy to analyse and fix it.

Oftwn when I tried "straight forward" in conjunction with
the IETF it ended up as disaster:  The toplabel task force
proposed on this list two years ago was so far unable to
fix a single word in RFC 1123.  The "4234 to STD" proposal
was supposed to be a no-brainer for four weeks, and ended
up as a major project with new drafts / stubborn authors /
interop testing and report / etc. until it ended as STD 68.
  
 Frank

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 25 Aug 2008 16:11:50 -0700

> versions as the weeks old "idn-tlds" (2606bis).

Personally, I would like to see a new draft addressing all resolved issues ASAP.

Pushing another revision is indeed very cheap.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 26 Aug 2008 09:27:28 GMT

>both  outside of that context (news-checkgroups more so,

Yes, I take your point about possible use of news-checkgroups in regularly
posted articles in *.annouce groups. It's no big deal, because the
introductory text already present indicates that control messages are the
primary intended use for both of these.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 26 Aug 2008 09:37:21 GMT

>now simpler than our form, but allows ">".

And that is the problem. The USEFOR draft permits a whole raft of ugly
stuff that is no longer permitted by 2822-bis (and good riddance to it).
It would be much simpler to say that our message-ids are the same as those
of 2822 bis, but without the obs-stuff and without that ">".

>for a sudden rush of AUTH48 modifications.

I doubt we are going to have any opportunity for any "*future* final
merger". If we don't do it now, it will never get done. I doubt any of it
would be the least bit controversial.