search

grittygrease / draft-colwell-privacy-txt

IETF draft for privacy.txt
Other
4 stars 2 forks source link

Draft -01 #4

Closed xcolwell closed 3 months ago

xcolwell commented 5 months ago

Addressing feedback from the first draft.

xcolwell commented 4 months ago

@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 commented 3 months ago

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

xcolwell commented 3 months ago

Regarding the URL section, should we just reference RFC3986?

grittygrease commented 3 months ago

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 https://github.com/grittygrease/draft-colwell-privacy-txt/pull/4#issuecomment-2192351818, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHDHZ32TZUNWFDXCFEGIN3ZJMABRAVCNFSM6AAAAABHIUFKKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGM2TCOBRHA . You are receiving this because you were mentioned.Message ID: @.***>

xcolwell commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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?