world" (tm) are RFC compliant (just like email processing, in general).
I'd recommend going with a more forgiving validation than one strictly
based on RFC BNFs."
As someone long involved in this, going back to RFC733 (predecessor to RFC822), I would be very cautious about offering that advice.
Jon Postel famously said "Be liberal in what you accept, and conservative in what you send." [RFC 760]. However, while this has a good deal of short-term pragmatics behind it, long experience has shown it not to be a good long-term strategy.
Notably, this was applied to the HTML standard, with disastrous results we are still recovering from. People send all kinds of invalid craps, and browsers and the like are expected to deal with them, and they cannot ever manage to all deal with them the same way. As a strategy, this can turn into a race for the bottom.
A lot would depend exactly why you're validating. If you're sending it on to somewhere else, I VIGOROUSLY urge you to do fully strict validation. This will help to prevent mishandling further down the line.
In fact, I find it hard to make any case at all for loose validation. There's valid, and invalid. Postel's law applies more to parsing, than validation.
But even then, you acceptance of invalid input risks misinterpretation, and you have to weight the risks vs benefits. Not such a problem for dates,say, but a huge problem if you deliver a message to the wrong recipient.
In the Real World, people do NOT have invalid email addresses. There once was a time when that was common -- but now, you REALLY,REALLY do NOT WANT an invalid address, because you will not even be able to enter your email address as an email address in many, many contexts.
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment