Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Hosting metadata #11
The draft is complicated significantly by virtue of constructing metadata from three sources:
(I think that I've gotten the order right here, but I'm not 100%)
If this is truly a content-encoding, then we can retain that property and simplify things greatly. Then the processing rules don't need to concern themselves with header fields at all.
What is the use case for including header fields in the secondary resource?
I agree that it's confusing, but I'm not quit sure which metadata your question is about :-)
Is this about 3) "the protected payload of the secondary resource"? The examples in Section 3.4 use it; 3.4.1 for Content-Language, 3.4.2 for encryption information.
Let's focus on 3.4.2 for now? Are you saying this is wrong/bad?
If we don't need the metadata in the protected payload then we wouldn't need the application/http media type, right?
3.4.2 is a less informative example, but sure. The
On the basis of 3.4.2 and
Crypto-Key is defined in https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00#section-4 as:
An Crypto-Key header field can be used to describe the input keying
So I think to make it apply to the secondary resource, some additional text is needed over there.
@Julian. This describes OOB without a resource map. How is this
2016-02-08 15:26 GMT+01:00 Julian Reschke email@example.com: