Re: [abnf-discuss] Wherefore no HTAB in literal text strings in ABNF
Sean Leonard <[email protected]> Thu, 18 Aug 2016 19:47:03 -0700
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
--===============8639267257464372761== Content-Type: multipart/alternative; boundary="Apple-Mail=_8D922E2C-A243-4F83-A2ED-B5DB2A31907C" --Apple-Mail=_8D922E2C-A243-4F83-A2ED-B5DB2A31907C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Aug 15, 2016, at 2:02 AM, Paul Overell <[email protected]> wrote: >=20 >=20 >=20 > On 15/08/16 02:34, Sean Leonard wrote: >> Hello Knowledgeable ABNF Folks: >>=20 >> I have been working with RFC 5234 lately. What is the rationale (or = what are the rationales) for including SP %d32 but excluding HTAB %d9 in = char-val, aka the literal text string? I am sure that this decision was = not an oversight. >>=20 >> It may be appreciated that the comment production is defined as WSP, = which includes HTAB. >>=20 >>=20 >=20 > char-val =3D DQUOTE *(%x20-21 / %x23-7E) DQUOTE > ; quoted string of SP and VCHAR > ; without DQUOTE >=20 > So that the contents of a string literal are visible and unambiguous = to a human reader - spaces and tabs look alike. For comments is doesn't = matter if the white space comprises of spaces or tabs, it doesn't change = the meaning of a comment. But for strings it's important for a human = reader to know exactly what's in them.=20 >=20 >=20 > Regards > --=20 > Paul Overell Thank you. That was one of the justifications that I was thinking, and = what I was looking for. Best regards, Sean= --Apple-Mail=_8D922E2C-A243-4F83-A2ED-B5DB2A31907C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 15, 2016, at 2:02 AM, Paul Overell <<a href="mailto:[email protected]" class="">[email protected]</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class=""> <div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><br class=""> </p> <br class=""> <div class="moz-cite-prefix">On 15/08/16 02:34, Sean Leonard wrote:<br class=""> </div> <blockquote cite="mid:[email protected]" type="cite" class=""> <pre wrap="" class="">Hello Knowledgeable ABNF Folks: I have been working with RFC 5234 lately. What is the rationale (or what are the rationales) for including SP %d32 but excluding HTAB %d9 in char-val, aka the literal text string? I am sure that this decision was not an oversight. It may be appreciated that the comment production is defined as WSP, which includes HTAB. </pre> </blockquote> <br class=""> <pre class="newpage"> char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE ; quoted string of SP and VCHAR ; without DQUOTE </pre> So that the contents of a string literal are visible and unambiguous to a human reader - spaces and tabs look alike. For comments is doesn't matter if the white space comprises of spaces or tabs, it doesn't change the meaning of a comment. But for strings it's important for a human reader to know exactly what's in them. </div></div></blockquote><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""> <br class=""> <br class=""> Regards<br class=""> <pre class="moz-signature" cols="72">-- Paul Overell</pre> </div> </div></blockquote></div><br class=""><div class=""><div>Thank you. That was one of the justifications that I was thinking, and what I was looking for.</div><div><br class=""></div><div>Best regards,</div><div><br class=""></div><div>Sean</div></div></body></html> --Apple-Mail=_8D922E2C-A243-4F83-A2ED-B5DB2A31907C-- --===============8639267257464372761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-822 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-822 --===============8639267257464372761==--