Hello Gerhard,
for similar use cases ("make some sense of the HS_SITE elements of prefixes) we have set up the 'SiteInfo service' [1] .
This helps our users to understand, which service is responsible for particular prefixes.
It also has a non-documented JSON interface for machine-actionable output (used by our monitoring systems to understand which mirror service replicates from which primaries).
Some time ago we moved away from RFC3651 (as of Nov 2003) and for our development work we have been consulting the source code of the Handle.Net software to understand the latest changes in various entries - I just name examplary the type 'HS_SITE.PREFIX'.
(We also started to draft some internal documentation in the style of RFC3651 about the new entries, but never finished. :) )
Our particular interest were the classes [2] that are responsible for resolution (check out SiteInfo.java, Encoder.java, etc).
Those are the classes, which are also used by the 'web server' you were also mentioning.
Having said this, the source code can be of help if you just need to understand how the latest implementation deals with various data types in details, but it is of course not an accepted definition of types.
[1] https://pidconsortium.net/siteinfo/
[2] https://www.handle.net/hnr-source/api-javadoc/net/handle/hdllib/package-summary.html
All the best,
Tibor
------------------------------------------------------------------------
Dr. Tibor Kalman
Group eScience
T: +49 551 201-1541, E-Mail: tibor.kalman@gwdg.de
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG)
Am Faßberg 11, 37077 Göttingen, URL: https://www.gwdg.de
Support: Tel.: +49 551 201-1523, URL: https://www.gwdg.de/support
Sekretariat: Tel.: +49 551 201-1510, Fax: -2150, E-Mail: gwdg@gwdg.de
Geschäftsführer: Prof. Dr. Ramin Yahyapour
Aufsichtsratsvorsitzender: Prof. Dr. Norbert Lossau
Sitz der Gesellschaft: Göttingen
Registergericht: Göttingen, Handelsregister-Nr. B 598
Zertifiziert nach ISO 9001
------------------------------------------------------------------------
> Am 18.03.2021 um 02:30 schrieb Gerhard Gonter <ggonter@gmail.com>:
>
> The venerable rfc3651[1] describes how data in Handle entries are
> encoded, so I tried to make sense of the HS_SITE element of our own
> 0.NA Handle entry [2]. I know, the rfc describes the binary structure
> of the Handle protocol data unit while the web server presents
> something interpreted. I assume, it is a hex dump of what would be
> expected as the original element. However, the structure of the
> HS_SITE element of [2] seems not to be matching what is described in
> the rfc [1]. For instance, the IP address of the Handle server can be
> found in there as "00000000000000000000000083820432" which should
> represent the IPv6 address of the machine while the rfc states it
> *should* be encoded there as "00000000000000000000FFFF83820432" :
>
> -- 8< ---
> <Address>
> The 16-byte IPv6 [15, 16] address of the handle server. Any
> IPv4 address should be presented as :::::FFFF:xxxx:xxxx (where
> xxxx:xxxx can be any 4-byte IPv4 address).
> --- >8 ---
>
> I know, the "should" here is not a "MUST" as defined in rfc 2119 [3].
> However, it does not match. There are other parts of the HS_SITE
> element that do not match (IMHO) the description in rfc3651, but if
> anyone can point me to an up-to-date documentation of the data
> structures (or other documentation relevant for the Handle System), I
> will try to make more sense of what i can find in live data.
>
> * [1] https://tools.ietf.org/html/rfc3651#page-17
> * [2] http://hdl.handle.net/0.NA/11353
> * [3] https://tools.ietf.org/html/rfc2119
>
> regards, Gerhard Gonter
> _______________________________________________
> Handle-Info mailing list
> Handle-Info@cnri.reston.va.us
> http://www.handle.net/mailman/listinfo/handle-info
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/mailman/listinfo/handle-info