Re: [dispatch] Two week review: Progressing draft-mohali-dispatch-originating-cdiv-parameter as AD sponsored

[[e-mail] (Dale R. Worley)]

Paul Kyzivat <[e-mail]> writes:
>>> registration-state-param = "regstate" EQUAL ["un"] "reg"
>>
>> That's correct, but only slightly simpler.  And I fear that people would
>> mis-read it as allowing (or even requiring)
>>
>>     regstate=un reg
>>
>> Are there other places we've done constructions like this?
>
> I don't know.
>
> Clearly this is a matter of taste.

I tried to get some evidence regarding the styles that have been used in
RFCs.

    grep '[^ ]" *[]] * "' rfc????.txt

turns up a hundred or so situations where BNF has an optional string
literal concatenated with a string literal.  But in almost all of those,
one of the strings is punctuation.

To limit the situation to when two "identifier" string literals are
adjacent, I did 

    grep -i '[a-z]" *[][] * "[a-z]' rfc????.txt

Most of those hits are some sort of e-mail filtering language where
juxtaposition isn't concatenation.  The remaining examples are:

    rfc1014.txt:           [ "unsigned" ] "int"
    rfc1014.txt:         | [ "unsigned" ] "hyper"
    rfc1832.txt:           [ "unsigned" ] "int"
    rfc1832.txt:         | [ "unsigned" ] "hyper"
    rfc4506.txt:           [ "unsigned" ] "int"
    rfc4506.txt:         | [ "unsigned" ] "hyper"

which are versions of the XDR specification, and though the grammar
doesn't state it very clearly, "unsigned" means a *token* not a
*string*, etc., so the first line means that once the text has been
tokenized, there is either "unsigned" followed by "int", or only "int".

Dale