Fix: #936. Cache semantics impacts on Digest and on the representation.

[ioggstream]

This PR

Clarifies the following points:

• resource identification is inherited from SEMANTICS
• validator fields (ETags & Last Modified) which apply to the identified resource, apply to Digest too.

[ioggstream]

I'll merge the content-location stuff and leave the resource identification to this issue (which is the hard part). This will push forward the ongoing work on POST/PATCH.

[ioggstream]

@reschke @LPardue PTAL :)

[reschke]

Consider me confused.

Currently, the draft says:

"The resource is specified by the effective request URI and any validator field contained in the message."

...and then, in that section, doesn't mention "resource" anymore.

What was the intent of that statement? Can't it be just removed?

[ioggstream]

Currently, the draft says:

"The resource is specified by the effective request URI and any validator field contained in the message."

...and then, in that section, doesn't mention "resource" anymore.

What was the intent of that statement?

The statement originates from https://tools.ietf.org/html/rfc3230#section-4.3.2 .
My understanding is that the original author stated explicitly that Digest must be aligned with Last-Modified & co.
This could be trivial though...

Can't it be just removed?

It is reasonable to me to remove the whole statement

 The resource is specified by the effective request URI and any validator field contained in the message

and delegate the resource specification to https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#target.resource

@LPardue @mnot WDYT?

[ioggstream]

My bad, Mark replied #949 (comment) with the above proposal. Let's do it then!

[ioggstream]

Current wording integrates @reschke and @mnot suggestion (iiuc).

[mnot]

Generally, we try to avoid re-stating requirements in other specs, or constraining how they're interpreted, because that makes the composition of the specs more brittle -- there's more chance of misinterpretation or unintentional misalignment (either as written or after some future change in the dependency).

So if you say anything at all, it shouldn't be a RFC2119 requirement; just some prose about the relationship for reader convenience.

[ioggstream]

Thanks @mnot. Let's drop those lines then!

[LPardue]

This new text look technically fine but the sentence is a bit long winded now, especially with the
parameter comment in brackets. How about some editorializing like this, which intentially avoids saying anything about parameters.

A representation digest consists of a `digest-algorithm` followed by an `encoded digest output`.

~~~ abnf
   representation-data-digest = digest-algorithm "="
                                <encoded digest output>
~~~

The `digest-algorithm` identifies both an algorithm and output encoding format which are applied
to a representation. A checksum value is first computed on the entire selected `representation data`
(see Section 7 of {{SEMANTICS}}) of a resource identified according to Section 7.3.2 of {{SEMANTICS}}.
This is then encoded using the required format.

The list of defined `digest-algorithms` is provided in {{algorithms}}.

The example below shows the `sha-256` digest-algorithm which uses base64 encoding.

~~~ example
   sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
~~~

[ioggstream]

If this is technically ok, I suggest to:

• merge and close the issue;
• resolve Clarify digest-algorithm syntax with parameters (or drop parameters). #850 (parameters);
• rewording in another PR.

In the rewording, we could even avoid mentioning the "encoding" part as I think it should only be mentioned in the digest-algorithm section.

WDYT?

[LPardue]

sgtm

[LPardue]

Yeah I forgot about the clash with 850. Let's land this and I see you've made a signpost back to my editorial suggestion so we don't lose it.

[ioggstream]

Ok, to me this is complete. I'll leave to @LPardue the decision to merge or to wait for further feedback.