Mention relative URLs

[michielbdejong]

No description provided.

[michielbdejong]

@acoburn @Vinnl please review

[Vinnl]

As a normative rule, this doesn't sound like too useful an idea: both clients and servers will have to support both code paths, because either doesn't know what the other will do.

But if the spec is mostly describing what current implementations do... Well, I'm not too sure what my review would add, since I'm not familiar with those implementations :)

[michielbdejong]

OK, so I agree it would be a pretty useless feature to add as part of the spec, but I just tested it locally with NSS and it turns out you can use sub /data/test instead of sub https://example.org/data/test and then you will also receive pub /data/test instead of pub https://example.org/data/test.

The code for this is here, you can see it just takes url.parse(iri).path and then does store the uri separately so that it can be reproduced at pub time.

[michielbdejong]

I think it's useful to add as many notes like this as possible, wherever NSS or another implementation diverges from the spec, and whenever a feature is at risk because we're having discussions about removing or updating it.

[Vinnl]

If one of the options (either relative or absolute) is supported by all current implementations, then I'd just go with that one. Clients can then simply assume that, and new server implementations do not need to feel forced to implement the other option too.

Of course implementations are free to include whatever they want on top of the spec - I wouldn't call that "diverging". If it's possible to find common ground, though, I'd keep that as the canonical way of complying with the spec, and would consider the rest undocumented behaviour.

[michielbdejong]

But can we add a note in the spec about the existence of that undocumented behaviour, just to make our lives easier?

[Vinnl]

Yes, that's what I intended to say - but apparently forgot while writing the rest of the comment :P As long as it's clear what the required implementation is, mentioning that some implementations also add an alternative option can't really harm, I guess.

[michielbdejong]

OK, interpreting that as a positive review for adding this remark, then. Thanks! :)

[RubenVerborgh]

Guys, we want too fast here. Spec changes require more eyes than this.

I oppose the change because it leaves open who should support what. Does this mean that clients MUST support relative URLs? SHOULD servers support them? It introduces a level of vagueness that is not good for a spec.

I'll update the repo settings to require 2 reviews for PRs, unless there are objections.

[acoburn]

I'm a little late to the discussion here, but one question I'd have about the language here is "relative to which host". It is entirely possible for a Solid server to serve resources at http://resources.example.com, and to then have an Updates-VIA point to http://events.example.com where the notifications are received. In that case, (presumably) you should not use relative paths because in this context, those paths would be relative to the http://events.example.com host and not the http://resources.example.com host. In principle, I could also imagine a scenario in which multiple resource hosts have events aggregated at a single notification server.

That said, @RubenVerborgh makes a much more important point about the speed of changes to a specification. While I a don't want to introduce needless process or slow everything down, there are definite advantages to having more perspectives on these sorts of substantive changes.

Somewhat related: I think it would be a good idea to separate normative language from non-normative language, which would clarify whether this sort of example is actually a MUST level feature or if it's just a possibility that an implementation may consider.

[RubenVerborgh]

Yes, I was also thinking about that; presumably relative to WSS URL.

My preference would be a revert of this commit, and then we write down what it needs to be. But in any case, created #182 to follow up since this PR is closed.