Subject: [Enum] Insensitivity?

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 14 Jan 2004 22:02:17 +0000

Hi folks,
  does anyone actually implement the case insensitivity flag in ENUM?

I had assumed that the i at the end was a typo in the examples in
RFC3403, as my eyes must have glazed over when reading section 3.2
of RFC3402 (on extended Regular Expression replacement syntax).
[Warning - strong coffee/tea is needed before attempting this]

I have just seen two of these "out in the wild", and wonder if
anyone's client will handle them, or reject it as invalid (as ours
all do at present, and a couple of other clients I've been using :(.

Heads up, folks!

This is another change in expected behaviour with the introduction of
references to 340x in rfc2916bis - I don't think it was there in 2916.
all the best,
   Lawrence

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 14 Jan 2004 23:28:26 +0000

Hi again folks,
 From RFC3402, ss 32:
    'Furthermore, any backref replacements MAY
     be normalized to lower case when the "i" flag is given'.
I do so love that MAY.
I agree that the substitution expression will be applied to an E.164 
number (with the initial +).
Thus the i flag is not really important for the ERE for the ENUM DDDS 
Application.
However, with the sentence I've quoted, it may matter for the REPL.

AFAICT, rfc2916bis does not require ENUMservice specifications to be 
case insensitive in
the URIs they produce, so we can't just tolower() everything, as some 
URIs MAY be Case-Sensitive.
(Look at the SIP archive for much past fun on case sensitivity vs. case 
insensitivity).

That was not the point I was trying to make, however.
Every client I've seen doesn't ignore the i flag, it barfs (currently 
including SER and *).

Thus we have not reached standards-compliance in the clients out there, 
so beware.

all the best,
   Lawrence

On 14 Jan 2004, at 10:57 pm, dlist wrote:

> As E164 numbers, domain names and user parts are always case 
> insensitive, I think any user agent should treat the regexp case 
> insensitive regardless of the presence of the
> i flag.
>
> ---
> Adrian Georgescu
> www.ag-projects.com
>
>
>
> On 14 Jan 2004, at 23:02, Conroy, Lawrence (SMTP) wrote:
>
>> Hi folks,

---

From: dlist <[email-masked]>
Date: Wed, 14 Jan 2004 23:57:59 +0100

---
Adrian Georgescu
www.ag-projects.com

---

From: [email-masked]
Date: Sun, 18 Jan 2004 01:38:10 +0900 (JST)

Hello, I'm Kazunori Fujiwara, JPRS.

> From: dlist <[email-masked]>

for example, http URI is case sensitive.

> From: "Conroy, Lawrence (SMTP)" <[email-masked]>
> Hi again folks,
>  From RFC3402, ss 32:

I read that this sentence says any backref value may be normalized to lower.
but in case of ENUM, any backref value contains '+' and digits only.
other replacement field may be written in lower case.
So, I think 'i' flag is needless in ENUM.

We need sample implementation of ENUM client library.
Is there a sample implimentation?

I'm writing ENUM client library in Perl.

I want to discuss ENUM client and DNS, Registry implementation.

-- 
Fujiwara, Kazunori	JPRS (.JP Registry)

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 17 Jan 2004 20:51:54 +0000

Hi Fujiwara-san, "dlist", Folks,
    I agree with you. The 'i' REGEXP flag is ineffective for ENUM 
entries.

For ENUM:
(i) the Key (to which the ERE is applied) consists only of '+' and a 
sequence of digits, so the 'i' flag has no impact, and
(ii) the optional normalisation will have no impact, as any matched 
part of the AUS will also consist only of '+' and/or a sequence of 
digits so the backrefs are not effected.
(iii) Whatever else is in the REPL part is not effected, and can 
contain any legal characters - it will NOT be normalised to lower case 
regardless of the presence of an 'i' flag (at least from the 
perspective of RFC3402 compliance).

*  One could make a very good argument that, for ENUM, the i flag has 
no effect at all; it's pointless.

*  However, pointlessness does not stop some benighted folks from 
putting the completely redundant 'i' into ENUM NAPTRs.

Whether or not there is a mechanism to find the person who put in such 
an ENUM entry and to slap them around the face with a wet kipper (to 
indicate to them that this practice has caused a number of busy 
programmers to change code to no useful purpose) is an topic For Future 
Study; IMHO, it's not the subject of IETF standardisation, except 
perhaps for one day in a couple of month's time.

*  Thus, I believe that any ENUM client implementation should IGNORE 
this flag, not barf as most do right now.

all the best,
   Lawrence

On 17 Jan 2004, at 7:49 pm, dlist wrote:

> Yes it is, but is on the right part of the regular expression, "i" 
> does not apply to it.
>
>
> On 17 Jan 2004, at 17:38, [email-masked] wrote:
>

---

From: dlist <[email-masked]>
Date: Sat, 17 Jan 2004 20:49:10 +0100

Yes it is, but is on the right part of the regular expression, "i" does 
not apply to it.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Jan 2004 07:18:09 +0100

Note that the NAPTR regexp spec is acting on UTF-8 encoded Unicode, and 
"case insensitivity" is not defined for the Unicode Character set 
(without specification on exactly how the mapping is done).

As Lawrence points out, the matching is on digits and '+' anyway, so 
there is nothing which really can be case sensitive or insensitive.

     paf

On 2004-01-17, at 21.51, Conroy, Lawrence (SMTP) wrote:

> programmers to change code to no useful purpose) is an topic For 
> Future Study; IMHO, it's not the subject of IETF standardisation, 
> except perhaps for one day in a couple of month's time.
>