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

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

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