Draft -01

[xcolwell]

Addressing feedback from the first draft.

• Edits and Formalism: align with references/conventions from existing RFCs, references to existing RFCs, clearer definitions
• Alignment of terms with the direction of industry language. "Privacy policy" versus "Privacy notice"
• Tool to check and create a privacy.txt policy for any site
• Acknowledgement notes to feedback and reviews

[xcolwell]

@lvanderpeet I think the spec should define the encoding of a boolean attribute. Is it 0/1 or false/true?

Alternatively, something to consider, I've been thinking it might be more human readable to work with nominal values instead of booleans. Consider the following two equivalent Cookie lines:

test,foo.com,300,false,true,false,true
test,foo.com,300,first,optional,no-httponly,secure

I feel like the second one is much more readable. What do you think?

Field#4: first or third
Field#5: optional or required
Field#6: httponly or no-httponly
Field#7: secure or no-secure

[xcolwell]

@grittygrease do you have more changes pending? I'm starting to work on fixing the build now.

[xcolwell]

Regarding the URL section, should we just reference RFC3986?

[grittygrease]

That seems fair. security.txt has some robust text here: https://datatracker.ietf.org/doc/rfc9116/ A field MUST always consist of a name and a value (for example: "Contact: ***@***.***"). A "security.txt" file can have an unlimited number of fields. Each field MUST appear on its own line. Unless otherwise specified by the field definition, multiple values MUST NOT be chained together for a single field. Unless otherwise indicated in a definition of a particular field, a field MAY appear multiple times. Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per Section 2.1 of [RFC3986]).

…

On Wed, Jun 26, 2024 at 2:12 PM Brien Colwell ***@***.***> wrote: Regarding the URL section, should we just reference RFC3986 <https://datatracker.ietf.org/doc/html/rfc3986>? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHDHZ32TZUNWFDXCFEGIN3ZJMABRAVCNFSM6AAAAABHIUFKKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGM2TCOBRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[xcolwell]

Merging the General file format, URL, and Email sections together into General File Format with this language makes sense.

I also think a more concise format definition would be UTF-8 encoded (RFC3629) and use \n as a line separator. Multiple whitespace (RFC5892) are collapsed into a single space, and excess space is ignored.

[xcolwell]

An example of merging General file format, URL, and Email into General file format:

The file format is UTF8 text and lists `Field:Value`, one per line. Whitespace and lines that start with `#` are ignored. All field are NOT case sensitive unless mentioned otherwise.  Each field MUST appear on its own line.  Unless otherwise specified by the field definition, multiple values MUST NOT be chained together for a single field. Unless otherwise indicated in a definition of a particular field, a field MAY appear multiple times.

`\n` is used a line break, and whitespace according to the [ASCII whitespace HTML spec](https://infra.spec.whatwg.org/#ascii-whitespace). Excess whitespace is ignored.

Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per Section 2.1 of [RFC3986]) and mailto URIs (as per [RFC6068])

[xcolwell]

@lvanderpeet For this spec NAME, can it just be URL encoded? Is there any reason we need to use a different encoding? Also why a limit on the length?