Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dhlamb leaves00:48
* github-ff joins02:04
[fcrepo4] dbernstein opened pull request #1155: Ensure Content-Type header for HEAD requests on containers mirrors wh… (master...fcrepo-2159) https://git.io/vM4lA
* github-ff leaves
* dwilcox joins07:27
* coblej joins08:40
* thomz leaves08:47
* kefo joins09:12
* dhlamb joins09:18
* dwilcox leaves09:19
* mikeAtUVa joins09:23
* peichman joins09:28
* bseeger joins09:45
* kestlund joins09:51
* kestlund1 joins10:02
* kestlund leaves10:04
* apb18 joins10:09
* dwilcox joins10:16
* whikloj joins10:26
* kestlund1 leaves10:50
* kestlund joins10:58
* apb18 leaves11:00
* barmintor joins11:04
* dwilcox leaves11:21
* kestlund leaves11:26
* kestlund joins
* barmintor waves at kestlund
* coblej leaves11:34
* coblej joins11:35
* coblej leaves12:03
* bseeger leaves12:04
* kestlund leaves12:07
* bseeger joins12:33
* coblej joins13:00
* kestlund joins13:07
* kestlund leaves13:29
* kestlund joins
* kestlund leaves
* ajs6f joins13:56
barmintor:awoods: I like the header-based approach for fixity mch better than messing with mimetypes.13:58
<barmintor>ajs6f: Do you mean options 2-3?
<ajs6f>And the reason is that you have a basic HTTP interaction, then you add the headers and get a richer interaction.
<barmintor>sorry, 2-4
<ajs6f>whereas with the mimetype thing, you have actually changed the values in the original interaction13:59
<barmintor>you would think I could successfully type two single digit numbers, but no
<ajs6f>or to put it another way, if you start with the fixity-enabled ixn, and you drop some headers, you have a perfectly find HTTP ixn.
barmintor: You need more fixity checks.
let me go see what numbers you gave things
<barmintor>ajs6f++ that it is a strong critque, probably the best one against the otherwise "just workiness" of the Accept: option14:00
<ajs6f>Number-wise, I'm saying I don't like 1), I don't much like 2) (I'm the anon who doesn't like inventing new headers)14:01
Hmmmm, 3 and 4
<barmintor>No one likes new headers if they want backfill-ability
Hm. They both suffer from the same weakness (that you point out) about intermediating servers.
Let me go read 3230 more carefully.
* kestlund joins
<barmintor>3230 is just there to document the format of the token in #4
<ajs6f>barmintor: I know what you meant, but I'm wondering about my pet dead horse to beat-- fixity that isn't small enough to fit in a header.14:03
How might that might or might not that might work or might now.
<barmintor>ajs6f: that's out of scope for this, right? We're talking about digest verification?14:04
* th5 joins
<ajs6f>barmintor: No, we're taking about things that are not digests-- IOW, I want to make sure that we can correctly use Digest and/or Expect to make those things work.
E.g. if the actual value _has_ to be quoted in the header, I'll have to think about it hard.14:05
<barmintor>ajs6f: I don't understand what you mean about "things that are not digests"
* peichman1 joins
<ajs6f>barmintor: http://dericed.com/papers/reconsidering-the-checksum-for-audiovisual-preservation/14:06
I have a/v archivists now telling me "Digests are not what we need. They don't help us preserve things."
* peichman leaves
<ajs6f>They don't know exactly what they want or need yet because our systems don't let them figure it out.14:07
I want to give them space to figure that stuff out.
So I want (at a simplistic level)
<barmintor>ajs6f: sure, but following "For digital preservation activities, the application of checksums is an essential recommendation;", fixity is what we're talking about
behavioral change is some other application consideration
Or at least, not from my POV.14:08
This is what we are talking about:
Urg, he put no anchors there. Search for "Whole-File Checksum plus framemd5"
framemd5 is a good example14:09
Sticking that into a header is silly, it's not going to work.
But I have real users now asking to use that as fixity.
<barmintor>I think that's describable with an Expect approach, but neither of the ones in that doc, which are checksum/digest approaches14:10
ajs6f: it's *not* describable in an approach that tries to use the Digest header14:11
because the Digest header would apply to the request body
<ajs6f>barmintor: Right, right, and I don't expect us to get this perfect righ tnow.
I just want to do as well as we can and go in the best direction we can.14:12
<barmintor>ajs6f: but the use case you describe may ward off the Expect + Digest approach
ajs6f: in favor of distinct expectations
<ajs6f>Well, that's the question I want to look at.
Expect may be the linchpin for this thing.14:13
<barmintor>ajs6f: it is also worth noting that "Whole-file Checksum plus framemd5" could be 2 requests14:14
or 2 exepctations on a single request
with a request body
<ajs6f>barmintor: Yep. Like I say, I don't expect (SEE WHAT I DID THERE) this to be perfect, I just want it to support my use cases as well as it can and be as exitensible as it can.14:15
<barmintor>ajs6f: also probably worth considering that proxies are probably not transmitting a request entity, which would be coming on a POST, so the intermediary concern may be irrelevant for you
at least, the caching proxies won't be14:16
<ajs6f>barmintor: Wait, you are talking about how the (say) framemd5 info gets there?
You are thinking in a req body?
<barmintor>ajs6f: yeah, where else would it go
<ajs6f>at the end of a link
<barmintor>at the end of a link14:17
<ajs6f>I admit that has its own funkiness
<barmintor>at the end of a link
<ajs6f>from the POV of transparancy
Yeah, a link in a header.
Say, Expect.
<barmintor>ajs6f: a Link header or a query parameter?
<ajs6f>No, sorry, neither-- I mean as part of the value of an Expect header.
<ajs6f>It's a particular kind of expectation.14:18
I don't think we can do that with Digest, but maybe we can?
<barmintor>ajs6f: do you mind if I add a link to that article and add the framemd5 use case to CON for the Accept option
Mos def.
<barmintor>ajs6f: I can see through the glass darkly Expect: 406-vary-by-link;rel=X;algorithm=Y + Link: <>;rel=X14:31
maybe Link: also has type=fixity14:32
<ajs6f>barmintor: That has tradition to recommend it. Someone who never heard of Fedora could stare at that for a while and maybe guess what it means.14:43
which is good
<barmintor>ajs6f: what is the http status when an algorithm is not supported?14:46
<ajs6f>You mean according to 3230?14:47
<barmintor>yeah, I don't see one
Yeah, weird, I don't see one either!14:48
418 https://www.quora.com/What-is-the-story-behind-HTTP-status-code-418-Im-a-Teapot14:49
<barmintor>ajs6f: I am guessing a note that it's 4xx != 417 != 406
<ajs6f>Or.... ignore14:50
MEaning ignore algorithms you don't understand.
<ajs6f>I agree, for us, but it might appear differently to people who aren't dealing with the same problems.14:51
<barmintor>actually, if it's the Expect
it probably *should* be a 417
since that expectation is not supported by the originating server
* barmintor has to meet with others14:52
<ajs6f>I thought you meant if it's Digest. Yes, unintelligible Expect I would EXPECT (SEEWHATIDIDTHERE) to produce 417
* ruebot is leaning toward option #414:53
<ajs6f>Me too14:55
<ruebot>406-vary-digest -- "vary" i think is the only confusing thing for me. but, that could just be my inexperience getting the best of me14:58
but, after talking it out with barmintor, i think i'm ok :-)14:59
* dwilcox joins15:08
<kestlund>barmintor: hi! finally paying attention…15:15
* dwilcox leaves15:26
* coblej leaves16:04
<barmintor>ajs6f: on the one hand, I like the elegance of the actual Digest: header and Expect: vary-by-digest, but I have to be very editorial about a defined header to get there, and that makes me uncomfortable on the other.16:31
but piling the digest token in as a param on the expectation is less editorial about other people's headers, even if it lacks the cute structural parallel with a hypothetical vary-by-link16:33
* kestlund leaves16:52
* mikeAtUVa leaves16:53
* whikloj leaves17:04
* bseeger leaves
* coblej joins17:05
* coblej leaves17:09
* coblej joins17:15
* coblej leaves17:25
* kefo leaves17:43
* peichman1 leaves17:46
* coblej joins
* coblej leaves17:53
* th5 leaves17:59
* ajs6f leaves18:13
* ajs6f joins18:28
* ajs6f leaves18:33
* ajs6f joins18:49
* ajs6f leaves18:55
* anarchivist leaves19:11
* jackhill leaves19:13
* jackhill joins19:14
* anarchivist joins19:21
* ajs6f joins19:33
* ajs6f leaves19:37
* ajs6f joins19:53
* ajs6f leaves19:58
* ajs6f joins20:14
* ajs6f leaves20:19
* peichman joins20:33
* peichman1 joins
* peichman leaves
* ajs6f joins20:35
* ajs6f leaves20:40
* peichman joins20:52
* peichman1 leaves
* dwilcox joins
* peichman1 joins
* peichman1 leaves20:54
* ajs6f joins20:56
* peichman leaves20:57
* ajs6f leaves21:01
* ajs6f joins21:17
* ajs6f leaves21:21
* ajs6f joins21:38
* ajs6f leaves21:43
* ajs6f joins21:59
* ajs6f leaves22:03
* ajs6f joins22:20
* ajs6f leaves22:25
* ajs6f joins22:40
* ajs6f leaves22:45
* ajs6f joins23:01
* ajs6f leaves23:06
* ajs6f joins23:22
* ajs6f leaves23:27
* ajs6f joins23:43
* ajs6f leaves23:48
* dwilcox leaves
* dhlamb leaves23:52
* ajs6f joins00:04
* ajs6f leaves00:08
* ajs6f joins00:25
* ajs6f leaves00:29
* ajs6f joins00:45
* ajs6f leaves00:50
* ajs6f joins01:06
* ajs6f leaves01:11
* ajs6f joins01:27
* ajs6f leaves01:32
* ajs6f joins01:48
* ajs6f leaves01:53
* ajs6f joins02:09
* ajs6f leaves02:14
* ajs6f joins02:30
* ajs6f leaves02:34
* ajs6f joins02:51
* ajs6f leaves02:55
* thomz joins03:10
* ajs6f joins03:12
* ajs6f leaves03:16
* ajs6f joins03:32
* ajs6f leaves03:37
* ajs6f joins03:53
* ajs6f leaves03:58