@@ -327,29 +327,19 @@ an annotation.
327327
328328Implementations:
329329
330- - SHOULD provide an implementation-specific best effort validation for each
331- format attribute defined in this document;[ ^ 3 ]
330+ - SHOULD provide validation for each format attribute defined in this
331+ document;
332332- MAY support format values not defined in this document, but such support MUST
333333 be configurable and disabled by default;
334334- SHOULD use a common parsing library or a well-known regular expression for
335335 each format;
336336- SHOULD clearly document how and to what degree each format attribute is
337337 validated.
338338
339- [ ^ 3 ] : The expectation is that for simple formats such as date-time, syntactic
340- validation will be thorough. For a complex format such as email addresses, which
341- are the amalgamation of various standards and numerous adjustments over time,
342- with obscure and/or obsolete rules that may or may not be restricted by other
343- applications making use of the value, a minimal validation is sufficient. For
344- example, an instance string that does not contain an "@" is clearly not a valid
345- email address, and an "email" or "hostname" containing characters outside of
346- 7-bit ASCII is likewise clearly invalid.
347-
348- The requirement for minimal validation of format values in general is
349- intentionally vague and permissive, due to the complexity involved in many of
350- the attributes. Note in particular that the requirement is limited to syntactic
351- checking; implementations SHOULD NOT attempt to send an email, connect to a URL,
352- or otherwise check the existence of an entity identified by a format instance.
339+ The requirement for validation of format values in general is limited to
340+ syntactic checking; implementations SHOULD NOT attempt to send an email, connect
341+ to a URL, or otherwise check the existence of an entity identified by a format
342+ instance.
353343
354344#### Custom format attributes
355345
0 commit comments