Greetings, TCG folks, but particularly Gretchen as Registry chair. I want to raise a potential problem with the design of the 'ivo:' identifiers in the VOEvent spec, which may be common to other uses of IVORNs in IVOA specs. I'm deliberately raising this _after_ the VOEvent 2.0 spec has been approved (including Sébastien's and my approval from the point of view of the Semantics group). I discussed the issue with Rob and Roy during the VOEvent RFC period: we had some very cordial discussion, but they ended up unconvinced that the problem was serious. Myself, I'm not so convinced of the severity of the problem, that I wanted to block the RFC, even if that were legitimate at that stage of the process. Also, this is arguably an architecture problem, and therefore beyond the scope of a single Recommendation's RFC. I think this is the sort of issue that the TCG or the Registry WG (on the grounds that it's that WG where the IVORN spec originated) might want to take a position on, or at least be aware of. Indeed... Suggestion: I think the TCG or the Registry WG should produce a Note indicating that using IVORNs with fragments is likely not to be future-proof, and should be avoided in future versions of standards. I hope it's clear why I restrict my comments below to VOEvent identifiers, but I think the issue is more general than this. -------- VOEvent identifiers have the form ivo://example.org/streamid#local_ID (see , section 2.2). The issue with this URI format is that the URI RFC 3986 states that the fragment (the '#local_ID') is removed prior to any dereference -- see section 3.5 of the URI RFC; other language there makes it clear that the fragment has a special, and secondary, status and that this cannot be redefined by scheme-specific specifications. The intention is that such a URI is handled by the client stripping the fragment, processing the resulting cropped URI, and then resolving the fragment _on the client_. It's that 'on the client' that's important. In the VOEvent spec, however, .../streamid and .../streamid#local_ID are conceived as completely independent resources, contrary to the presecriptions in the URI RFC. I think this is not merely a theoretical problem, for three reasons. (1) One can imagine a URI API which allows for scheme-specific handlers (eg for vos: or ivo:), in the way that the java.net.URI class does. Such a handler class/API could potentially be constructed in such a way that the handler code couldn't get access to the fragment part of the parsed URI. This would completely screw up a custom handler for "ivo:" URLs which included significant fragments. And _this would not be a bug_ in the API. The java.net.URLStreamHandler abstract class is not in fact constructed in this way, but that doesn't undermine the point. (2) Similarly, one can imagine a cache which, when it was asked for , would simply return the content of since, according to the URI spec, and for _any_ scheme, these are equivalent in this context. Indeed, I think any "ivo:" cache might be _required_ to behave like this (RFC section 6.1: "When URIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison.") This also is _not a bug_ in the cache. These two problems can be evaded: don't use scheme-specific handlers, and don't use proxies or caches. The last point is the longest-term point, and may not be so easily worked around. (3) URIs won't last forever. At some point -- perhaps in a decade, perhaps longer -- there will be a replacement standard. URis are so important that there will be a mechanism for mapping URIs to the new standard, supported by gateways or proxies of some type. Those gateways cannot be guaranteed to be friendly to URI schemes which depend on behaviour which the URI specification declares must not happen. -------- Best wishes, Norman -- Norman Gray : http://nxg.me.uk School of Physics and Astronomy, University of Glasgow, UK