Potential ISSUE: <utext> (was: ABNF nits)

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

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>