Understanding IVORNs

[Mike Fitzpatrick]

On Thu, Aug 14, 2014 at 6:35 PM, John Swinbank <j.swinbank at uva.nl> wrote:

>
> Based on the above, I have a two part question:
>
> 1. Does the “local_ID” following the “pound sign" in the example given in
> the VOEvent standard constitute part of the identifier or not?
>

My interpretation is "no", i.e. the intent is that the ivorn up to the '#'
is a resource identifier that can be resolved in the Registry to some
repository or event stream that when presented with the local_ID (via some
TBD access protocol) will return the corresponding event packet identified
by the 'local_ID' fragment of the URI.

Now, it also depends on what you mean by 'identifier' in your question:  If
you mean is local_ID part of the identifier for the packet then my answer
is yes, if you mean is it part of the identifier for the service/resource
then no.  So, having met Rob's challenge of giving contradictory responses
all by myself, I would also point out the discussion of the ambiguity in
Norman's IVOA Note on URI fragments (
http://www.ivoa.net/documents/Notes/URIFragments/20120525/NOTE-URIFragments-1.0-20120525.html)
and at the end of Sec. 2 of the VOEventRegExt doc where the meaning of the
ivorn could change depending on the client use or service (e.g. resolving
the ivorn to get connection information to an event stream, or using the
whole identifier to resolve to a single packet in a repository).  My
interpretation of that is that a client should resolve teh ivorn (up to the
fragment) using the RegExt capabilities results to decide whether/how to
use the fragment.



> 2. If so, do the same limitations in terms of reserved characters apply to
> the local_ID as to the rest of the IVORN?
>

According to the URI doc (RFC 2396:  http://www.ietf.org/rfc/rfc2396.txt),
they do (see Sec 4 on fragments which says syntax follows reserved chars
from Sec 2).


Cheers,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20140815/721f0f91/attachment.html>