Your summary matches mine. A new editor's copy is posted. When I finish the matching draft submission, maybe I'll consume another integer and submit this one as well. > > 3 - improve registry ABNF, simplify the corresponding chapter > > That was rejected, Addison wants to document the record-jar > format, not its registry incarnation. That's backwards from > my POV, mail (2822) and news (1036) use prose for the simple > general format, and syntax for the header field details, but > there's no rule to do it this way also in 3066bis. I suggested that an independent RFC be written to document record-jar for future generations, actually. In this case, I don't see the benefit of another ultra-complicated ABNF: I don't think it will save very much text, if any, and it is hard to read. Clarity is served by the current text/ABNF, I think. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: 2005?5?15? 21:12 > To: ltru at ietf.org > Subject: [Ltru] Re: Open points before -02 > > > 1 - check and fill gaps in Suppress-Scripts > > That was "rejected", the actual idea is to publish the registry > draft first (closing the old registry), and to finish the > business with the draft registry later. > > > 2 - check SHOULD, MUST, and rationale for Suppress-Scripts > > Addison proposed a rationale to be added in -02. Maybe Ira > and Randy still want to replace two corresponding SHOULD NOT > by some "MUST NOT unless". > > > 3 - improve registry ABNF, simplify the corresponding chapter > > That was rejected, Addison wants to document the record-jar > format, not its registry incarnation. That's backwards from > my POV, mail (2822) and news (1036) use prose for the simple > general format, and syntax for the header field details, but > there's no rule to do it this way also in 3066bis. > > > 4 - redefine canonical / deprecated to follow the underlying > > ISO and UN standards (stable forever != canonical forever) > > Already discussed elsewhere. The last idea was to replace the > "normative Canonical: xx" by an "informative Use: xx". > > > 5 - move redundant tags from draft registry to an appendix > > Alread discussed elsewhere. It's possible to arrange things > this way, the registry would be shorter, implementations would > be simpler, but after all that's mainly a matter of taste. And > it's already clear that I didn't like two MO-nsense entries. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru at lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.