On 11/27/24 18:18, Alessandro Vesely wrote: > On Wed 27/Nov/2024 02:41:03 +0100 Martin Thomson via Datatracker wrote: >> The schema defines a number of enums, which seem like they might be >> problematic >> if you ever need to extend the value space. I'm looking at DKIMResultType >> and >> SPFResultType as prime examples of something that might need to be extended. >> In these case, I generally recommend xs:token as well, pointing at a >> registry >> for the valid values. > > That seems to be a cute hint. Referring to IANA Email Authentication Result > Names shields the definition from any tweaks that might be introduced in the > future, and makes the grammar much shorter and readable.
One drawback would be that the people making the generators, cannot easily validate the values, like they can now. Who am I kidding, no-one seem to ever have done any XSD validation on their aggregate feedback report XML data. If we choose to go this route, would something like the below be acceptable? Is it too strict to specify "active" registrations, in case of future deprecations? In addition to the below, a similar change would be made for "spf", and the two types with the enumerated values would be removed. This was omitted for clarity, here. Some text would also need to be added in the proposed rewrite that is ongoing. I also changed the type to xs:token, as Martin suggested, I don't know if that is wanted or if we should just stick with xs:string? - <!-- The DKIM verification result. --> - <xs:element name="result" type="DKIMResultType" + <!-- The DKIM verification result. + For valid values, see the "active" registrations for "dkim" in + the IANA registry for Email Authentication Result Names. --> + <xs:element name="result" type="xs:token" Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
