Re: [whatwg] type=email validation is too loose for practical applications

2009-08-25 Thread Anne van Kesteren
On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org wrote:
 I'd like stricter rule for it. e.g.
 dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))

That does not work with IDNs.


-- 
Anne van Kesteren
http://annevankesteren.nl/


Re: [whatwg] type=email validation is too loose for practical applications

2009-08-25 Thread Aryeh Gregor
On Tue, Aug 25, 2009 at 2:59 AM, Anne van Kesterenann...@opera.com wrote:
 On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org wrote:
 I'd like stricter rule for it. e.g.
 dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))

 That does not work with IDNs.

Nor does the current spec, but it only restricts what the UA actually
submits, not what it accepts from the user.  The spec suggests that
UAs convert IDNs to punycode for submission, which seems reasonable.
Opera 9.64 seems to reject IDNs in input type=email (but I'm not
totally sure on this, my IDN might just be wrong somehow).


Re: [whatwg] type=email validation is too loose for practical applications

2009-08-25 Thread Anne van Kesteren
On Tue, 25 Aug 2009 15:19:42 +0200, Aryeh Gregor  
simetrical+...@gmail.com wrote:

Nor does the current spec, but it only restricts what the UA actually
submits, not what it accepts from the user.


Ah, that makes sense.



The spec suggests that
UAs convert IDNs to punycode for submission, which seems reasonable.


Though somewhat inconsistent with type=url, but then IDN email addresses  
are not quite there yet.




Opera 9.64 seems to reject IDNs in input type=email (but I'm not
totally sure on this, my IDN might just be wrong somehow).


We might not support them yet, I haven't checked.


--
Anne van Kesteren
http://annevankesteren.nl/


[whatwg] type=email validation is too loose for practical applications

2009-08-24 Thread TAMURA, Kent


http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state

A valid e-mail address is a string that matches the production

dot-atom-text @ dot-atom-text
where dot-atom-text is defined in RFC 5322 section 3.2.3.  
[RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322


I'd like stricter rule for it. e.g.
dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))

I understand the current production, dot-atom-text @ dot-atom-text, is a
subset of addr-spec of RFC 5322.  However dot-atom-text for the domain-part
is not practical.  The production accepts apparently unusable email address
like tk...@

--
TAMURA Kent
Software Engineer, Google





Re: [whatwg] type=email validation is too loose for practical applications

2009-08-24 Thread Peter Kasting
On Mon, Aug 24, 2009 at 5:19 PM, TAMURA, Kent tk...@chromium.org wrote:

 http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state
  A valid e-mail address is a string that matches the production
 dot-atom-text @ dot-atom-text
  where dot-atom-text is defined in RFC 5322 section 3.2.3. 
  [RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322

 I'd like stricter rule for it. e.g.
 dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))

 I understand the current production, dot-atom-text @ dot-atom-text, is a
 subset of addr-spec of RFC 5322.  However dot-atom-text for the domain-part
 is not practical.  The production accepts apparently unusable email address
 like tk...@


It would have been nice to send this email as a reply to the current
discussion about type=email validation (several messages sent earlier
today), especially since the argument there is for _less_-strict validation.

PK