Issues with the structure and contents of the draft

[yahesh]

I read through the current draft after I heard about it on Linkedin as I like the general idea.

Unfortunately, the structure of the current draft is not without issues:

• The field definitions are currently located in the introductory section.
• There should be one sub-section per introduced field.
• There should be a section about the general format of the file (instead of putting this into the introduction).
• There should be a section about the placement of the file (instead of putting this into the introduction).
• There should be a section about valid value formats for given fields.

The contents is also not without issues at the moment:

• It is unclear if the names of fields are case-sensitive or case-insensitive.
• It is unclear which characters (or character sequences) are allowed for line breaks.
• There should be a clear definition for each field if it is mandatory or optional.
• There should be a clear definition for each field if only one entry or multiple entries are allowed.
• The draft currently requires a URL or mailto:EMAIL to be used but doesn't reference corresponding RFCs like RFC3986 or RFC6068
• The draft currently uses combined fields like Entity and Banner where this is not necessary and complicates descriptiveness and introduces more complex processing (like having to escape and properly parse separators).
• Where combined fields are introduced, the draft doesn't specify the contents of the placeholders (like NAME, COUNTRY_CODE, CONSENT_PRESENT or CONSENT_PLATFORM). Instead, the field definitions just describe the contents of the field in sequential order and the reader of the draft currently has to discern on their own which part of the definition actually belongs to which placeholder.
• The draft currently introduces ambiguous value definitions in fields like Privacy-policy and Banner where this is not necessary and complicates processing (like "the consent management platform name, which can be set to non-specific-custom or any identifying name if it is a custom banner": the structure and source of "the consent management platform name" is not defined, the static value of non-specific-custom is introduced for "custom banner" solutions but at the same time this can also be set to "any identifying name", which devalues the formerly defined static value).
• The draft currently defines CONSENT_PRESENT as a "boolean attribute" but does not define how such a boolean value is to be expressed (true | false, 1 | 0, yes | no).
• The current draft lacks multi-language support. While the security.txt RFC is directed at security researchers which oftentimes have some proficiency in English to warrant a single contact URL, according to the introduction this draft is also meant to support consumers who might not be proficient in a specific language. Therefore, there should be the possibility to define language-specific privacy policy URLs.

In general it would be great if the authors of the draft could have a look how RFC9116 solved some of the aforementioned issues.

[xcolwell]

Draft-01 attempts to address these issues. #4

[xcolwell]

@yahesh The latest draft-01 has been published to the IETF data tracker (https://datatracker.ietf.org/doc/draft-colwell-privacy-txt/) and https://privacytxt.dev . We're asking for feedback on the latest. Our goal is to present at IETF Vancouver to get thoughts on an RFC track.