Subject: Re: Updated erratum

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 20 Jun 2008 08:12:23 +0200

Posted on the rfc.interest list:
 
>| Errata ID: 1081 (2007-11) was updated by Errata ID: 1353 (2008-03).
>| The fix proposed in ID 1353 is clearly better, e.g., ID 1081 allowed
>| (in theory) a toplabel 1-2-3, but ID 1353 requires a leading letter.  
>|
>+ If ID 1353 is verified this should trigger follow-up errata for RFCs
>| 3696, 4408, and ietf-usefor-usefor.  This list might be incomplete.

It might be also too long, RFC.ietf-usefor-usefor could be fixed in
AUTH48:  "<toplabel> is any LDH <label> starting with a letter, and
consisting of at least two characters" is a straight forward concept.

 Frank 

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Updated erratum
Date:  Fri, 20 Jun 2008 08:12:23 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 15
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Posted on the rfc.interest list:
 
>| Errata ID: 1081 (2007-11) was updated by Errata ID: 1353 (2008-03).
>| The fix proposed in ID 1353 is clearly better, e.g., ID 1081 allowed
>| (in theory) a toplabel 1-2-3, but ID 1353 requires a leading letter.  
>|
>+ If ID 1353 is verified this should trigger follow-up errata for RFCs
>| 3696, 4408, and ietf-usefor-usefor.  This list might be incomplete.

It might be also too long, RFC.ietf-usefor-usefor could be fixed in
AUTH48:  "<toplabel> is any LDH <label> starting with a letter, and
consisting of at least two characters" is a straight forward concept.

 Frank 

Date: Thu, 05 Jun 2008 16:06:26 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To:  [email-masked]
CC: Frank Ellermann <[email-masked]>
Subject: Re: [Fwd]: 2822 implementation report request
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>    
> 
>>Unlike the case of ABNF, where one settled for
>>"implementation = parser", and documented "use",
>>I don't think a fellow spec is going to be counted.....
> 
> 
> The 2234 report counted references, the difference
> here could be that RFC 2822 is not only yet another
> normative reference in RFC.ietf-usefor-usefor, we
> looked at numerous details down to obscure topics
> like "semantic content" of a <quoted-string>, the
> number of summaries, or the wonders of <obs-phrase>. 
> 
> 
>>but if anyone has a conformant implementation of
>>-usefor in his news system, that could also be a
>>2822 implementation to report....
> 
> 
> That would be of course better, but I'd guess that
> only IANA "implements" unnumbered RFCs.

If the draft document this group got out the door, (I won't
say produced) counts as an "implementation" of a standards
track IETF document, then I am very much misled about
what "implementation of a standard" means.

Based on Ellerman's meaning, I move we translate usefor
into Spanish, French, and Italian, declare them interoperable
implementations, and promptly notify the IETF of the milestone.

It really did feel like Kobayashi Maru simulation all those
years. It would be a fitting conclusion to change the exit
criteria.

- Forrest

P.S. I cannot believe I still read and care enough about this
attempt and effort to respond.

Anyone else still out there?

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: [Fwd]: 2822 implementation report request
Date:  Thu, 5 Jun 2008 20:23:18 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 21
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Harald Alvestrand wrote:
   
> Unlike the case of ABNF, where one settled for
> "implementation = parser", and documented "use",
> I don't think a fellow spec is going to be counted.....

The 2234 report counted references, the difference
here could be that RFC 2822 is not only yet another
normative reference in RFC.ietf-usefor-usefor, we
looked at numerous details down to obscure topics
like "semantic content" of a <quoted-string>, the
number of summaries, or the wonders of <obs-phrase>. 

> but if anyone has a conformant implementation of
> -usefor in his news system, that could also be a
> 2822 implementation to report....

That would be of course better, but I'd guess that
only IANA "implements" unnumbered RFCs.

 Frank

Date: Thu, 05 Jun 2008 12:15:28 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd]: 2822 implementation report request
Sender: [email-masked]

Frank Ellermann wrote:
> Hi, I think we could answer this reqest, suggestion:
>   

Unlike the case of ABNF, where one settled for "implementation = 
parser", and documented "use", I don't think a fellow spec is going to 
be counted..... but if anyone has a conformant implementation of -usefor 
in his news system, that could also be a 2822 implementation to report....
> | RFC 2822 / 2822upd Implementation Questionnaire
> | =======================> |      0. Contact and Description
> |         Organization Name:
> + IETF USEFOR WG
>
> |         Implementation (Software or Service) Name:
> + draft-ietf-usefor-usefor-12 (approved standards track RFC)
>
> |      1. Have you implemented RFC2822?
> + Yes, the RFC 1036 format used to build on RFC 822, the
> + revides NetNews formats builds on RFC 2822 (normative
> + reference importing major parts of the RFC 2822 syntax)
>  
> |      2. For how long it has been deployed?
> + January 2007 
>
> |      3. What features have NOT been implemented from RFC2822?
> + Chapter 4 (obsolete syntax), NO-WS-CTL in <msg-id>, 
> + [CFWS] in traditional NetNews header fields, more than
> + one summary header field (see appendix C of the draft)
>
> |      4. What features of RFC2822 are problematic for your implementation?
> + With two exceptions the obsolete syntax is not supported.
> + NetNews header fields require a space after the colon
> + between header field name and body, and don't allow any
> + folding before the first non-WSP character of the header
> + field body.
>
> |      5. Please add any other comments you wish to share:
> + The USEFOR WG welcomes the simplified <msg-id> syntax as
> + proposed in 2822upd.
>
>  Frank
>
>
>   

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: [Fwd]: 2822 implementation report request
Date:  Mon, 2 Jun 2008 21:30:03 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 39
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hi, I think we could answer this reqest, suggestion:

| RFC 2822 / 2822upd Implementation Questionnaire
| ===============================================
|      0. Contact and Description
|         Organization Name:
+ IETF USEFOR WG

|         Implementation (Software or Service) Name:
+ draft-ietf-usefor-usefor-12 (approved standards track RFC)

|      1. Have you implemented RFC2822?
+ Yes, the RFC 1036 format used to build on RFC 822, the
+ revides NetNews formats builds on RFC 2822 (normative
+ reference importing major parts of the RFC 2822 syntax)
 
|      2. For how long it has been deployed?
+ January 2007 

|      3. What features have NOT been implemented from RFC2822?
+ Chapter 4 (obsolete syntax), NO-WS-CTL in <msg-id>, 
+ [CFWS] in traditional NetNews header fields, more than
+ one summary header field (see appendix C of the draft)

|      4. What features of RFC2822 are problematic for your implementation?
+ With two exceptions the obsolete syntax is not supported.
+ NetNews header fields require a space after the colon
+ between header field name and body, and don't allow any
+ folding before the first non-WSP character of the header
+ field body.

|      5. Please add any other comments you wish to share:
+ The USEFOR WG welcomes the simplified <msg-id> syntax as
+ proposed in 2822upd.

 Frank

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  [Fwd]: 2822 implementation report request
Date:  Mon, 2 Jun 2008 20:27:28 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 51
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

[[[copy of an article posted on the IETF rfc822 list by Tony Hansen]]]

The IETF will shortly be considering elevating the revised mail format 
specification RFC 2822, to the second-level standards status of DRAFT.

A requirement for this is to produce information about implementations 
of the protocol specification.  It is therefore essential that we 
assemble a credible collection of information about actual development 
and interoperability testing -- and deployment is a form of testing -- 
for RFC 2822.

Because mail is a rich and widely-deployed protocol, the goal of this
query is to ask for enough information to be useful, but not to place
undue burden on responders by asking them to do a massive checklist.

It is assumed that most implementations of RFC 2822 have implemented all
of its required (MUST) features and probably a fair number of its
optional (SHOULD or MAY) features.

This survey does NOT cover any specifications outside of the RFC2822
document itself.  No enhancements, options, or the like.

Please take some time to complete the following questionnaire and send
me a private note with your responses.  I will assemble them into a
public report.

Please respond by June 10 2008.

RFC 2822 / 2822upd Implementation Questionnaire
===============================================
     0. Contact and Description
        Organization Name:
        Implementation (Software or Service) Name:

     1. Have you implemented RFC2822?
     2. For how long it has been deployed?
     3. What features have NOT been implemented from RFC2822?
     4. What features of RFC2822 are problematic for your implementation?
     5. Please add any other comments you wish to share:

Thank you.

Tony Hansen
[email-masked]

PS. This note borrows heavily from the 2821 implementation request email
by Dave Crocker.