Subject: [abnf-discuss] "A".."Z" syntax

From: Sean Leonard <[email-masked]>
Date: Sat, 21 Nov 2015 07:45:59 -0800

Section 2.3 of [RFC2978] “IANA Charset Registration Procedures” has the following ABNF:

     ALPHA        = "A".."Z"    ; Case insensitive ASCII Letter
     DIGIT        = "0".."9"    ; Numeric digit

Essentially, I interpret the syntax “..” is taken to mean all integers between the last character of the capitalized version of the preceding string, and the first character of the capitalized version of the succeeding string, as well as all integers between the last character of the lowercased version of the preceding string, and the first character of the lowercased version of the succeeding string.

Is this a syntax that folks think might be useful for standardization? Or not?

Most recently I had to use ABNF to define a string that starts with any alpha characters, except for “urn” (all case-insensitive). The current format is:

 	      aop           = ( %x41-54 / %x56-5A / %x61-74 / %x76-7A )	
 	                                               0*30ldh alphanum /	 		
 	                      "u"  ( "-" / DIGIT / %x41-51 / %x53-5A /	
 	                           %x61-71 / %x73-7A ) 0*29ldh alphanum /	
 	                      "ur" ( "-" / DIGIT / %x41-4D / %x4F-5A /	
 	                           %x61-6D / %x6F-7A ) 0*28ldh alphanum	
 
But it could be:

 	      aop           = ( "A".."T" / "V".."Z" ) 0*30ldh alphanum /	
 		
 	                      "u"  ( "-" / DIGIT / "A".."Q" / "S".."Z" )
                                                      0*29ldh alphanum /	
 	                      "ur" ( "-" / DIGIT / "A".."M" / "O".."Z" )
                                                      0*28ldh alphanum

One can only speculate how this might interact with %s in [RFC7405].

Thanks,

Sean

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 21 Nov 2015 13:09:23 -0500

Sean,

The first question that comes to my mind is: precisely what does this 
*mean*? You show "A".."Z". But "A" and "Z" in abnf are case insensitive. 
It would be a bit clearer for:

     %s"A"-%s"Z".

Do you want "A".."Z" to mean the same as:

     (%s"A"-%s"Z")/(%s"a"-%s"z")

or do you have something else in mind?

And what would the following mean?

     %s"Z"-%s"a"

The *simplest* definition (for case *sensitive* strings) would be every 
code point in the ASCII table between the first and the last. (So the 
example above would include "[", etc. that fall between "Z" and "A".)

	Thanks,
	Paul

On 11/21/15 10:45 AM, Sean Leonard wrote:
> _______________________________________________
> abnf-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abnf-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Nov 2015 12:25:34 -0800 (PST)

> > Most recently I had to use ABNF to define a string that starts with any
> > alpha characters, except for “urn” (all case-insensitive). The current format
> > is:

> > ...

> If it hurts, don't do it. Seriously. I'd stick with a simple ABNF and
> then just put the additional constraint into prose.

In most cases I agree 100% with this sentiment. There can be exceptions,
however, e.g., where the restriction needs to be immediately enforced as 
streaming data is read. In such a case it may be useful to encode the
restriction in the ABNF so it translates directly to catching errors during
the lexing phase.

But outside such cases, as a practical matter it's usually much easier to check
a token for a particular pattern of characters and reject it than it is to wire
such checks into the underlying tokenizer. So spelling stuff out in prose that
translates easily to token testing is actually doing implementors a favor.

More generally, when such cases come up I recommend thinking about how whatever
you're doing is likely to be implemented, and writing things in a way that you
believe is most helpful to implementors.

Academic purity is nice, but at the end of the day what counts is getting good
implementations out in the field.

				Ned

---

From: Sean Leonard <[email-masked]>
Date: Sat, 21 Nov 2015 18:57:58 -0800

On 11/21/2015 10:09 AM, Paul Kyzivat wrote:
> *mean*?

I stated it in my original post:
Essentially, I interpret the syntax “..” is taken to mean all integers 
between the last character of the capitalized version of the preceding 
string, and the first character of the capitalized version of the 
succeeding string, as well as all integers between the last character of 
the lowercased version of the preceding string, and the first character 
of the lowercased version of the succeeding string.

> You show "A".."Z". But "A" and "Z" in abnf are case insensitive. It 
> would be a bit clearer for:
>
>     %s"A"-%s"Z".
>

Yes (except that your syntax is not in RFC 5234, since the - is only 
good for %d %x and %b). It's the same as:
%x41-5A / %x61-7A

Specifically this is not a novel construction--it's how RFC 2978 uses it.

> And what would the following mean?

%x5A-61

>
> The *simplest* definition (for case *sensitive* strings) would be 
> every code point in the ASCII table between the first and the last. 
> (So the example above would include "[", etc. that fall between "Z" 
> and "A".)

Yes.

Anyway, per the other posts--I was mainly speculating, rather than 
making a formal proposal. The case-sensitive version doesn't provide 
anything significantly more powerful than what is already possible with 
%tA-B syntax. Only the case-insensitive version is interesting, and in 
some ways it can get obscure, when you're not specifically going through 
some subset of A - Z.

I guess I was curious if the authors/editors of RFC x234 (2234, 4234, 
5234) were aware of the RFC 2978 syntax, and explicitly rejected it.

Sean

>> Essentially, I interpret the syntax “..” is taken to mean all 
>> integers between the last character of the capitalized version of the 
>> preceding string, and the first character of the capitalized version 
>> of the succeeding string, as well as all integers between the last 
>> character of the lowercased version of the preceding string, and the 
>> first character of the lowercased version of the succeeding string.
>>
>> Most recently I had to use ABNF to define a string that starts with 
>> any alpha characters, except for “urn” (all case-insensitive). The 
>> current format is:
>>
>>                                                        0*29ldh 
>> alphanum /

---

From: Paul Overell <[email-masked]>
Date: Sun, 22 Nov 2015 15:48:18 +0000

> 5234) were aware of the RFC 2978 syntax, and explicitly rejected it.

(As co-editor RFCx234) I'll put my hand up to probably not being aware
of the .. syntax in RFC2978 - or if I was I would have thought it was a
succinct, informal, description of ALPHA and DIGIT, already defined in
RFC2234. 

RFC2234 pre-dates RFC2978, and both RFC4234 and RFC5234 just fixed some
minor issues, they didn't change or extend ABNF.   AFAIR .. was neither
proposed nor rejected.

As far the .. syntax itself is concerned, were it to be proposed it
would need some care to get the definition right.  "A".."Z" maybe simple

>Essentially, I interpret the syntax “..” is taken to mean all integers
between the last character of the capitalized
>version of the preceding string, and the first character of the
capitalized version of the succeeding string, as well as >all integers
between the last character of the lowercased version of the preceding
string, and the first character of >the lowercased version of the
succeeding string.

Would interpret "A".."z" as

%x41-5A / %x61-7A

But one might reasonably expect "A".."z" to mean %x41-7A.

The above definition makes no reference to non-alphabetic characters. 
How to interpret "z".."{"?  One might reasonably interpret this to mean
%x5A / %x7A / %x7B, but with the definition above it means %x5A-7B /
%x7A-7B.

I'm not arguing for or against .. , or for any particular
interpretation, but I think formally combining the two concepts of an
ASCII range, and that of case insensitivity is problematic.

Regards

-- 
Paul Overell

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Nov 2015 19:46:17 +0100

Best regards, Julian