On Oct 3, 2011, at 1:46 AM, Julian Reschke wrote: > On 2011-10-03 09:29, "Martin J. Dürst" wrote: >> On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip >> Hallam-Baker: >> >>>> Only real issue for me is that it has to fit in URI type slots. The >>>> scheme I was thinking of would be a pure URN scheme, your proposal >>>> includes URL like things. >> >> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at >> all; in RFC 3986, I think slashes would even be allowed if they don't >> appear directly after the first ':'), then you can define an URI scheme >> without including host-like stuff and you don't have to use "urn:" as a >> prefix. >> >>> Yep. We have use-cases for that. Note though that the authority >>> part is optional, so a fairly bare digest is quite possible and >>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... >> >> The triple slash at the beginning is a bad idea. There should only be >> slashes if the scheme conforms to the generic syntax (i.e. a double >> slash, something like a host name, and then slashes for something >> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. > > ... > > Also keep in mind that if you use "/" for a different purpose than hierarchy, > surprising things will happen when relative references are resolved. It's > good to avoid them in this case.
That's silly for this case. The proposed URL scheme has no hierarchy scheme, nor is it even resolvable because there is no host. I know Phill has already responded that he intends to use an encoding that changes Base64 for the reason you give; I believe that will lead to likely lack of interop due to complexity. --Paul Hoffman _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
