Frank Ellermann | 2 Jun 2008 20:27
Picon
Picon

[Fwd]: 2822 implementation report request


[[[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
(Continue reading)

Frank Ellermann | 2 Jun 2008 21:30
Picon
Picon

Re: [Fwd]: 2822 implementation report request


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
(Continue reading)

Harald Alvestrand | 5 Jun 2008 12:15
Picon

Re: [Fwd]: 2822 implementation report request


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)
(Continue reading)

Frank Ellermann | 5 Jun 2008 20:23
Picon
Picon

Re: [Fwd]: 2822 implementation report request


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

Forrest J. Cavalier III | 5 Jun 2008 22:06

Re: [Fwd]: 2822 implementation report request


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.
(Continue reading)

Frank Ellermann | 20 Jun 2008 08:12
Picon
Picon

Re: Updated erratum


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 


Gmane