Appropriateness of message/external-body

[acoburn]

No description provided.

[barmintor]

In the case of Columbia, having a way for some clients to indicate content that should be proxied, but is not appropriate to offer as a link to a client, is an important use case. Further, when seeking feedback on binary storage in Cavendish, I've received more feedback about having C be able to negotiate local files than about storing binaries "natively". So I think that there is a case for access-type=local-file, but the more general case of access-type=url is less clear to me.

[ajs6f]

What does access-type=local-file mean in the case of a distributed implementation that shards data?

[barmintor]

the way that I read the RFC is that the message/external-body MIME is to be used in conjunction with another Content-Type value and is relevant to the recipient on that interaction. So in the case of any implementation, I'd suggest it mean act like my message body is at the path indicated in the name parameter. I don't think it's appropriate if the server is the sender, for example.

[ajs6f]

So for some distributed implementation, it might be that some nodes will successfully answer the request and some won't? I'm not raising that as an instantly insuperable objection (although it doesn't sound ideal)-- just trying to make sure the consequences are clear. I guess I'm wondering if this the use case for access-type=local-file is one of these things where folks who need that will end up needing to select an impl that actually guarantees to do it, whether or not message/external-body is in the spec.

[barmintor]

These are good questions, @ajs6f. Just as context: I think something that has to be reckoned with is that presenting as a file system is a frequent integration mechanism- URL protocols might have taken the place of this once upon a time, but I've never seen e.g. the Java url-IO mechanisms be enthusiastically received. So now we see networked storage interfaces on private networks instead.

[ajs6f]

That's very true. To be clear, I'm not arguing that message/external-body doesn't have utility-- it clearly does. The question I'm raising (and I think the question that @acoburn raised) is whether that utility is both so large and so impossible to substitute that it demands inclusion in the spec, from which it would follow that every impl (including those for which the kind of integration to which you just pointed makes no sense or is impossible) would have to reckon with it.

[barmintor]

Good points. I'm trying to write something up, but maybe the right thing to do here is at least initially write it up as an auxiliary. I have to defer the question of largeness (my opinion is distorted by the centrality of the use case for MPOW). "impossible to substitute" is an intriguing thing to consider, as (I hope obviously) the function here is more important to me than the mechanism, but this does seem like a natural fit to me (worth noting that @acoburn read the same specs with somewhat different conclusions). I'd be lying if I said I haven't been looking for alternatives, though.

[barmintor]

There is a tempting read of Content-Location as documenting an original location (keep a reference) and Content-Type:message/external-body as documenting a transient location (copy it), but the admonitions about PUT and POST make me uncomfortable.

[barmintor]

The stored-reference models don't completely address the concerns about Want-Digest, either. Local file references, meh sure, but proxied URL content is a kettle of fish.

*edit: I don't allay other people's concerns 😳 *

[ajs6f]

Yeah, the fixity thing is a whole 'nuther story for this kind of function. I think it's fair to say (without meaning to tangle threads) that if the fixity functions don't land in the spec, that other story would be resolved. But it would leave the basic question that @acoburn raised.

[awoods]

@acoburn : I believe this issue has been resolved with: #121
If you agree, would you please close this issue?

[awoods]

Resolved with #121