Re: [abnf-discuss] Wherefore no HTAB in literal text strings in ABNF

Paul Overell <[email protected]> Mon, 15 Aug 2016 10:02:20 +0100
Newsgroups gmane.ietf.rfc822
Message-ID <[email protected]> 
This is a multi-part message in MIME format.
--===============0757963814510422139==
Content-Type: multipart/alternative;
 boundary="------------164C1F0F9802EC02F7BBF2BC"

This is a multi-part message in MIME format.
--------------164C1F0F9802EC02F7BBF2BC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit



On 15/08/16 02:34, Sean Leonard wrote:
> 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.
>
>

   char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; quoted string of SP and VCHAR
                                ;  without DQUOTE

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.


Regards

-- 
Paul Overell


--------------164C1F0F9802EC02F7BBF2BC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 15/08/16 02:34, Sean Leonard wrote:<br>
    </div>
    <blockquote
      cite="mid:[email protected]"
      type="cite">
      <pre wrap="">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>
    <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. <br>
    <br>
    <br>
    Regards<br>
    <pre class="moz-signature" cols="72">-- 
Paul Overell</pre>
  </body>
</html>

--------------164C1F0F9802EC02F7BBF2BC--


--===============0757963814510422139==
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

--===============0757963814510422139==--