Re: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Hi Pim

 

Just a follow up question:

 

Iâm reading about the formatting of the BDXL record here: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+BDXL+1.6#eDeliveryBDXL1.6-ConstructingtheDNSquery. If I understand correctly, then:

 

1. You generate a sha256 hash from the party identifier. This produces a 64 character string.
2. The 64 character hash string is base32 encoded. This produces a new 104 character string.
3. Any trailing â=âs are removed. The final string is then 100+ character.

 

However, any single label in a DNS name cannot be more than 63 characters long. How do you get around that?

 

/Kenneth

 

 

 

From: <bdxr@lists.oasis-open.org> on behalf of Pim van der Eijk <pvde@sonnenglanz.net>
Date: Friday, June 26, 2020 at 11:50 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

 

 

On 24-06-2020 14:21, Kenneth Bengtsson wrote:

Hi Pim

 

Glad your following the work in the TC even if not attending meetings! :-)

 

We havenât started discussing the format of the hostname yet, nor whether this should be prefixed or which hashing algorithm to use. Our observation is that different implementers are implementing different algorithms (as you are also pointing out), which drives up complexity and cost for software developers and integrators. Backwards compatibility is an inevitable issue when standardizing something that hasnât been standardized before. The appropriate RFC 2119 keyword for a backwards compatible spec would probably be âSHOULDâ.

 

/Kenneth

 

If you go for a recommendation,  the eDelivery BDXL format convention would be the better option than the old one from SML as it avoids the useless (and possibly problematic) "B-" prefix and uses a more capable hashing algorithm.  It is the outcome of extensive discussions ..