Hi Ed

On Tue, 22 Feb 2022 at 09:54, Edward Shryane via db-wg <[email protected]> wrote:
>
> Hi Massimo,
>
> > On 21 Feb 2022, at 16:29, Massimo Candela via db-wg <[email protected]> wrote:
> >
> > Hi Ed,
> >
> > Thanks for the work done.
> >
>
> Thank you!
>
> >
> > On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
> >
> >> We will also start enforcing the same validation on "remarks: geofeed" as 
> >> on "geofeed:" for consistency.
> >
> > I think you should not enforce anything on remarks. For what I know, 
> > remarks have been a free text field up to now.
> >
>
> I agree! In general, Whois doesn't attempt to validate free-text fields, 
> since they can contain anything, in any format.
>
> However, the RFC draft that we base the implementation on, allows for a 
> "remarks: geofeed <url>" as an alternative to a "geofeed:" attribute:
>
>    Ideally, RPSL would be augmented to define a new RPSL geofeed:
>    attribute in the inetnum: class.  Until such time, this document
>    defines the syntax of a Geofeed remarks: attribute which contains an
>    HTTPS URL of a geofeed file.  The format MUST be as in this example,
>    "remarks: Geofeed " followed by a URL which will vary.
>
> (Ref. 
> https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
>

Just a point on the RFC. As I have said in many discussions recently,
wording is important. The RFC says "Until such time...". We have a
"geofeed:" attribute now so we are past 'such time'. We should no
longer even consider, or support, "remarks:'' as an option for
geofeed. (Maybe after a defined transition period of time.) We have a
precedent for this with abuse contacts. People used to put them in
"remarks:" until we introduced "abuse-c:". Now we advise people to use
"abuse-c:" and not put abuse contact details in "remarks:". We should
give the same advice for "geofeed:". Of course some people still put
abuse details in "remarks:" as well, and they may continue to do so
with "geofeed:". It has a free text format so people can put whatever
they like there and the DB software should not try to parse it in any
way.

cheers
denis
co-chair DB-WG

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Reply via email to