On Mon, Oct 3, 2011 at 11:00 AM, Paul Hoffman <[email protected]> wrote: > > 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, [email protected] answered Phillip >>> Hallam-Baker: >>>
>> >> 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. Complexity, shmexity. We have a case where Julian has pointed out that failing to properly address these cases will lead to interop failures. I don't see how using the URI-safe encoding in a URI is more complex than using the one we already know to be broken. URLs are used in cases where hierarchy is assumed. Thus there is code to attempt to apply relative naming to identifiers that are put in URI slots. Julian is completely right on this. This is a known issue and the IETF already has a standards based fix for it. There is a fine line between simple and simplistic. Using the +/ encoding would be simplistic and definitely not simple. Interop issues due to incompetent programmers not reading the spec will on average be detected in (64/2) / ((4/3)*(256/8)) trials, that is 0.75. We can even choose test vectors that ensure that these issues are exposed. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
