Clarify that the endpoint name is a Unicode string

[chrysn]

Contributes-To: #190

---

WIP, will continue there tomorrow (checking whether any other place in the document needs adaption, whether there's any place where to reiterate RFC6690's "is not expected to validate UTF-8 encoding (but is not prohibited from doing so) and doesn't need to perform any UTF-8 normalization", and whether RD-DNS-SD still uses ep and d as it did where the 63 byte limit came from.

[petervanderstok]

I don't see any conflict with rd-dns-sd, a reference from rd-dns-sd to the RD draft looks appropriate.

[chrysn]

It seems no further changes are needed – when ep gets encoded it is passed into Link Format which is already Unicode; lookup filtering also draws from there; those references also pull in the no-need-to-decode parts (and when it comes to accepting endpoint names, that's a policy issue anyway).

RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays.

[petervanderstok]

RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays. actually that is explicitly mentioned, Peter chrysn schreef op 2019-03-11 10:12:

It seems no further changes are needed - when ep gets encoded it is passed into Link Format which is already Unicode; lookup filtering also draws from there; those references also pull in the no-need-to-decode parts (and when it comes to accepting endpoint names, that's a policy issue anyway). RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays. -- You are receiving this because you commented. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links: ------ [1] #207 (comment) [2] https://github.com/notifications/unsubscribe-auth/AMWTQZcvwag6DH3CPuTEf_uN70hrbuj2ks5vVh4RgaJpZM4bnhwQ