Identifiers 2.0 Public RFC results

[Tom McGlynn (NASA/GSFC Code 660.1)]

Hi Markus,

That's for adding in the examples in the new draft.  I think I learned a 
few things just reading them over and I really think they make it easier 
to understand.

Looking at your response to my comments in the RFC page:

    - I saw a space instead of a ~ using the SeaMonkey web browser which 
uses the same rendering engine as FireFox I think.
    - With regard to the redundancy of one of the must-nots: as sense 
is  there was redundancy if % was not an unreserved character.  But I 
couldn't tell since <unreserved> is never defined and it was too tedious 
to actually check it out in the likely reference document..  I've done 
so now and my understanding is that this is the definition of unreserved:

    unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

Since % is not one of these characters, you can't % escape another 
unreserved character since that implies using % which is not one of the 
characters you're allowed.   So I think that the MUST not is indeed 
redundant in the sense that it forbids no authority that would be legal 
under all of the other rules.

It's not a big deal -- the redundancy is harmless -- but I think it 
illustrates why it would be nice to have the definition of unreserved in 
the document.   It doesn't take much space and it makes it much more 
self-contained -- you can check its consistency without having to make 
external references.  I'd prefer to be able to use a single document to 
be able to tell if my ID's are valid or not.

     Tom

Markus Demleitner wrote:
> Dear Registry,
>
> The public RFC for Identifiers 2.0 has yielded two sets of interesting
> and helpful comments (thanks!).  I've tried to take them into account
> in a new version of the Identifiers document; you can view the diffs
> with a subversion client on
>
> https://volute.g-vo.org/svn/trunk/projects/registry/Identifiers
>
> or just download the whole built document from
> http://docs.g-vo.org/Identifiers.pdf (for a while).
>
> The most extensive change is that I've given up the attempt to re-use
> the term IVORN, which in the PR was intended to mean "An IVOID
> directly pointing to a registry record".  I had hoped the few cases
> of historical use that didn't match that were mine and I knew about
> them, but on Mark's insistence I finally tried to verify this, and it
> turns out there's just too much previous usage of the term "IVORN" in
> the VOEvent community that I had missed and that directly contradicts
> the meaning proposed here.
>
> However, much of that use also contradicts statements on IVORNs that
> were made in Registry.  So, I decided it's actually a good thing that
> the term URN has been deprecated.  Given the existing mess we have
> good reasons to follow this example with respect to IVORNs (there's
> also the detail that they've never really been URNs in the first
> place), so that's what I'm doing now in the document.
>
> An IVOID without a local name is now called a Registry reference, the
> part of an IVOID that must resolve in the Registry is the Registry
> part.
>
> Given this is a fairly serious change, I'd like to give everyone
> interested another opportunity to re-read things.  I would, however,
> like to go to TCG review some time between now and Oct 10th or so.
> If you forsee you can't make it till then please let me know.
>
> Thanks,
>
>            Markus
>