Hi, +1 I agree with Randy - machine-readable formats are regularly published in RFCs, without problems - the user community and IANA have scripts and C tools to strip the RFC artifacts from the various machine-readable formats. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald at sharplabs.com > -----Original Message----- > From: ltru-bounces at lists.ietf.org > [mailto:ltru-bounces at lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: Friday, July 08, 2005 6:54 PM > To: LTRU Working Group > Subject: [Ltru] issue #1059 Horizontal whitespace > > > Hi - > > > From: "Mark Davis" <mark.davis at jtcsv.com> > > To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU > Working Group" <ltru at ietf.org> > > Sent: Friday, July 08, 2005 3:38 PM > > Subject: Re: Horizontal whitespace (was Re: [Ltru] Re: I-D > ACTION:draft-ietf-ltru-initial-01.txt) > > > > > I agree with the goal. I'd suggest explaining in a bit more > detail, however: > > > > Headers, footers, line breaks, and other > > vertical whitespace introduced by the RFC process are not > > significant. Leading horizontal whitespace indicates a continued > > line in the record-jar format, and must not be deleted.=> > > > > In the IANA registry that is produced from this document in > the record-jar > > format, leading horizontal whitespace is significant, and > indicates a > > continued line. However, in this document, headers, > footers, line breaks, > > and other whitespace is introduced by the RFC process. To correctly > > interpret the data in this document, these extraneous > characters must be > > disregarded. In particular, a number of horizontal > whitespace characters > > that is greater than what is found on the 'File-Date' line > indicates a > > continued line in the record-jar format, and must not be deleted. > ... > > As a contributor who has edited RFCs establishing registries, > and who has > chaired WGs producing such RFCs, I feel quite confident in > saying that this > is complete and total over-kill. We don't do this for ABNF, > MIB modules, > ASN.1 modules, or any of the other machine-parseable stuff that finds > itself published in RFCs. The folks at IANA have repeatedly > proven that > they know enough to strip headers, footers, etc. I could > support Doug's > original proposal because it addressed a not-100%-obvious > potential problem, > but I can't support this amended proposal. If the rest of > the WG supports > it, I won't oppose it, but I think the amended proposal would > set a bad precedent. > > Randy > > > > > _______________________________________________ > 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.