This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Previous message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Next message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jori Vanneste
tyrasuki at pm.me
Thu Apr 8 16:17:54 CEST 2021
Hi Ed, On 4/8/2021 3:36 PM, Edward Shryane via db-wg wrote: > Hi Jori, > >> On 8 Apr 2021, at 14:42, Tyrasuki <tyrasuki at pm.me> wrote: >> >> Hi Ed, >> >> This seems like a good implementation to me. >> >> However, I don't think it's a good idea to limit the values on the "remarks" attribute in this way, as this could cause unwanted side effects with for ex. messages left on objects for other network operators. > Given the draft states: > > " Any particular inetnum: object MAY have, at most, one geofeed > reference, whether a remarks: or a proper geofeed: attribute when one > is defined." > > Do we enforce this by validating that there is only one "remarks: Geofeed" value (or "geofeed:") in the object? My apologies, I think I missed this section in the draft, thanks for clarifying the reason to me. >> Also: >>> "Do not support non-ASCII values in URL domain names or path (these must be converted beforehand)" >> Do you by this mean not supporting non-ASCII entirely? Or to have for ex. the web-interface convert IDNs to punycode, and have this listed on the object? >> > The RIPE database uses the Latin-1 character set, so IDN domain names or non-ASCII values in the URL path will be substituted with a '?' character, by default. > > We could support non-ASCII values by automatically converting them (like we do with non-ASCII domains in email addresses). That sounds like a good approach to me, thanks for clarifying. :) I think this is indeed a good starting ground for a minimal NWI, and would like to see where this goes. >> If the latter, and remarks can remain free-form, I'd say let's implement. >> >> >> Cheers, >> Jori Vanneste >> FOD11-RIPE >> > Regards > Ed Best regards, Jori Vanneste FOD11-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x27A401F86B85D0BC.asc Type: application/pgp-keys Size: 10332 bytes Desc: OpenPGP public key URL: </ripe/mail/archives/db-wg/attachments/20210408/19060a6c/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/db-wg/attachments/20210408/19060a6c/attachment.sig> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/db-wg/attachments/20210408/19060a6c/attachment-0001.sig>
- Previous message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Next message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]