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

Interesting research. I don't know what to make of it.

IMO it is merely a matter of which people find easiest to understand. I 
personally find them equally clear and easy, so I don't have much of an 
opinion one way or the other.

But I don't have much sympathy for people who think the two mean 
something different. If they don't correctly understand what these mean 
then that is a problem. They will have many more problems understanding 
the rest of sip and sdp. ABNF is *not* difficult. If you can program in 
*any* language (including Javascript, XML, SQL) then should have no 
trouble with it. If you can't, then you also shouldn't be trying to 
interpret specs like this in detail.

	Thanks,
	Paul

On 1/13/17 8:14 PM, Dale R. Worley wrote:
> Paul Kyzivat <paul.kyzivat@comcast.net> 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
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>