digest: editorial remarks on Appendix A

[reschke]

I tried to follow the examples but found them slightly confusing.

The following examples show how representation metadata, payload transformations and method impacts on the message and content. When the content contains non-printable characters (e.g. when it is compressed) it is shown as a Base64-encoded string.

1. payload -> content, right?
2. I think it would be easier to use hex encoding, because it would make it easier to follow what happens with ranges.

Now the same content conveys a malformed JSON object, because the request does not indicate a content coding.

3. Maybe: "removing the content coding from the same request causes the content to become malformed"

A Range-Request alters the content, conveying a partial representation.

4. "alters the content" is technically correct, but can easily be read as somehow affecting the server state. Maybe "affects the transferred message content"

Figure 5: Partial response from a gzip-encoded representation

5. To which server state does this refer? The one after executing the PUT in figure 3?

The method can also alter the content.

6. (see above)

Finally, the semantics of an HTTP response might decouple the effective request URI from the enclosed representation.

7. We removed "effective request URI" in RFC 9110, see end of https://www.rfc-editor.org/rfc/rfc9110.html#section-7.1)

[reschke]

"effective request URI" appears again in B.9. Digest with PATCH

[ioggstream]

@reschke is "target URI" ok?

[reschke]

Yes.

[ioggstream]

Hex encoding will be ~ 100 chars. I agree that it can be easier to understand
but it will be noisy too. Ideas?

[reschke]

Hex encoding will be ~ 100 chars. I agree that it can be easier to understand but it will be noisy too. Ideas?

Given the fact that the spec already has to deal with long lines in examples I don't think that's a problem.