[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ltru] issue #1059 Horizontal whitespace



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.