Re: [db-wg] "status:" attribute values in the RIPE database
Dear Colleagues, We have now run the cleanup job to uppercase all "status:" attribute values, and updated 23,890 objects in total. Regards Ed Shryane RIPE NCC > On 24 Aug 2021, at 13:39, Edward Shryane via db-wg wrote: > > Dear Colleagues, > > After starting work on the implementation, we discovered that "status:" > values are *already* automatically converted to uppercase on update. This was > implemented in Whois release 1.73.1 and deployed on 27th May 2014, but > existing non-uppercase values were not cleaned up at the time. > > I propose simplifying the implementation plan as follows: > > (1) Update Whois business rule validation (already implemented) > > When a non-uppercase "status:" value is converted to uppercase, a global > informational message is added to the response: > > ***Info:Value %s converted to %s > > (2) Cleanup existing non-uppercase "status:" values in the RIPE database > > On next *Monday 30th August*, we will run a cleanup script to convert all > existing non-uppercase "status:" values to uppercase. > > We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of > 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a > non-uppercase "status:" value. > > As only the case of the "status:" value is changed, the objects remain > syntactically the same. We will *not* send notification emails to maintainers > for the change, apart from notifying the db-wg. The "last-modified:" value > will not change, but a new object version will be created (so the change will > be visible in the version history). > > All changes will be visible in NRTM as the objects are updated. The change > can be considered a NOOP. > > All changes will be visible in that night's database dump and split files. > > We expect the cleanup script to take approximately an hour to complete all > updates. > > Cleanup script updates will be applied cooperatively between normal updates, > we do not expect any interruption to Whois updates. > > Regards > Ed Shryane > RIPE NCC > > > >> On 28 Jul 2021, at 17:15, Edward Shryane via db-wg wrote: >> >> Dear Colleagues, >> >> Thanks to the co-chairs for declaring a consensus, the DB team will start >> working on the implementation. >> >> The implementation plan consists of two parts: >> >> (1) Update Whois business rule validation >> >> We will add a business rule to require the "status:" attribute value in >> inetnum, inet6num and aut-num objects to be completely in UPPERCASE. >> >> This business rule will apply when creating or updating these object types. >> >> If the "status:" value is not completely in uppercase, the software will >> automatically convert the value to uppercase and add a warning in the update >> response, immediately following the "status:" attribute: "***Warning: The >> status value was converted to uppercase". The update will not fail if this >> happens. >> >> We plan to deploy this change in the next Whois release (provisionally, >> version 1.102). >> >> (2) Cleanup existing non-uppercase "status:" values in the RIPE database >> >> Following the Whois release, we will run a cleanup script to convert all >> existing non-uppercase "status:" values to uppercase. >> >> We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of >> 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a >> non-uppercase "status:" value. >> >> As only the case of the "status:" value is changed, the objects remain >> syntactically the same. We will not send notification emails to maintainers >> for the change, apart from notifying the db-wg. The "last-modified:" value >> will not change, but a new object version will be created (so the change >> will be visible in the version history). >> >> All changes will be visible in NRTM as the objects are updated. The change >> can be considered a NOOP. >> >> All changes will be visible in that night's database dump and split files. >> >> We expect the cleanup script to take approximately an hour to complete all >> updates. >> >> Cleanup script updates will be applied cooperatively between normal updates, >> we do not expect any interruption to Whois updates. >> >> Please let me know if you have any questions. >> >> Regards >> Ed Shryane >> RIPE NCC >> >> >>> On 27 Jul 2021, at 15:59, denis walker wrote: >>> >>> Colleagues >>> >>> The chairs recognise a consensus to force "status:" values to >>> uppercase on updates and for the RIPE NCC to perform a one time update >>> across the database to convert existing "status:" values to uppercase >>> where necessary. >>> >>> We ask the RIPE NCC to go ahead with this process and inform the >>> community of their implementation plans. >>> >>> regards >>> William & denis >>> co-chairs DB-WG >>> >>> On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg >>> wrote: Dear colleagues, In Remco van Mook's presentation to the Address Polic
Re: [db-wg] "status:" attribute values in the RIPE database
Dear Colleagues, After starting work on the implementation, we discovered that "status:" values are *already* automatically converted to uppercase on update. This was implemented in Whois release 1.73.1 and deployed on 27th May 2014, but existing non-uppercase values were not cleaned up at the time. I propose simplifying the implementation plan as follows: (1) Update Whois business rule validation (already implemented) When a non-uppercase "status:" value is converted to uppercase, a global informational message is added to the response: ***Info:Value %s converted to %s (2) Cleanup existing non-uppercase "status:" values in the RIPE database On next *Monday 30th August*, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase. We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value. As only the case of the "status:" value is changed, the objects remain syntactically the same. We will *not* send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history). All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP. All changes will be visible in that night's database dump and split files. We expect the cleanup script to take approximately an hour to complete all updates. Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates. Regards Ed Shryane RIPE NCC > On 28 Jul 2021, at 17:15, Edward Shryane via db-wg wrote: > > Dear Colleagues, > > Thanks to the co-chairs for declaring a consensus, the DB team will start > working on the implementation. > > The implementation plan consists of two parts: > > (1) Update Whois business rule validation > > We will add a business rule to require the "status:" attribute value in > inetnum, inet6num and aut-num objects to be completely in UPPERCASE. > > This business rule will apply when creating or updating these object types. > > If the "status:" value is not completely in uppercase, the software will > automatically convert the value to uppercase and add a warning in the update > response, immediately following the "status:" attribute: "***Warning: The > status value was converted to uppercase". The update will not fail if this > happens. > > We plan to deploy this change in the next Whois release (provisionally, > version 1.102). > > (2) Cleanup existing non-uppercase "status:" values in the RIPE database > > Following the Whois release, we will run a cleanup script to convert all > existing non-uppercase "status:" values to uppercase. > > We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of > 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a > non-uppercase "status:" value. > > As only the case of the "status:" value is changed, the objects remain > syntactically the same. We will not send notification emails to maintainers > for the change, apart from notifying the db-wg. The "last-modified:" value > will not change, but a new object version will be created (so the change will > be visible in the version history). > > All changes will be visible in NRTM as the objects are updated. The change > can be considered a NOOP. > > All changes will be visible in that night's database dump and split files. > > We expect the cleanup script to take approximately an hour to complete all > updates. > > Cleanup script updates will be applied cooperatively between normal updates, > we do not expect any interruption to Whois updates. > > Please let me know if you have any questions. > > Regards > Ed Shryane > RIPE NCC > > >> On 27 Jul 2021, at 15:59, denis walker wrote: >> >> Colleagues >> >> The chairs recognise a consensus to force "status:" values to >> uppercase on updates and for the RIPE NCC to perform a one time update >> across the database to convert existing "status:" values to uppercase >> where necessary. >> >> We ask the RIPE NCC to go ahead with this process and inform the >> community of their implementation plans. >> >> regards >> William & denis >> co-chairs DB-WG >> >> On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg wrote: >>> >>> Dear colleagues, >>> >>> In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What >>> Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that >>> resource "status:" attribute values may not always be all UPPERCASE. >>> >>> This is because the RIPE database is case-insensitive and case preserving >>> in general, meaning a "status:" attribute value is the same regardless of >>> the case. >>> >>> However, this may make parsing this value more
Re: [db-wg] "status:" attribute values in the RIPE database
Hi Taking my co-chair hat off, my personal view is, yes it is a bad idea to add a remark. This has been done many times in the past where objects have been modified as part of an agreed update. Some of these remarks have never been removed. They have been there for over 10 years. Objects then get bloated with multiple remarks about several updates. It just becomes unnecessary clutter. If the update has been well announced on the mailing list, maintainers have been notified of the modification and it shows in the object history then I don't think a remark is needed as well. cheers denis On Wed, 4 Aug 2021 at 16:06, Sylvain Baya wrote: > > Dear DB-WG, > > Le mer. 28 juil. 2021 à 4:15 PM, Edward Shryane via db-wg a > écrit : >> >> Dear Colleagues, >> > > Hi Edward, > Thanks for your notification, brother. > > >> >> Thanks to the co-chairs for declaring a consensus, the DB team will start >> working on the implementation. >> >> The implementation plan consists of two parts: >> >> [...] >> As only the case of the "status:" value is changed, the objects remain >> syntactically the same. We will not send notification emails to maintainers >> for the change, apart from notifying the db-wg. The "last-modified:" value >> will not change, but a new object version will be created (so the change >> will be visible in the version history). > > > > ...ok, cool! > Question, please: is it a bad idea to add a > comment as in "remarks:" attribute? > > Shalom, > --sb. > > >> >> All changes will be visible in NRTM as the objects are updated. The change >> can be considered a NOOP. >> >> All changes will be visible in that night's database dump and split files. >> >> [...] >> >> Please let me know if you have any questions. >> >> Regards >> Ed Shryane >> RIPE NCC >> >> > >> >> [...] >> >> >>
Re: [db-wg] "status:" attribute values in the RIPE database
Dear Colleagues, Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation. The implementation plan consists of two parts: (1) Update Whois business rule validation We will add a business rule to require the "status:" attribute value in inetnum, inet6num and aut-num objects to be completely in UPPERCASE. This business rule will apply when creating or updating these object types. If the "status:" value is not completely in uppercase, the software will automatically convert the value to uppercase and add a warning in the update response, immediately following the "status:" attribute: "***Warning: The status value was converted to uppercase". The update will not fail if this happens. We plan to deploy this change in the next Whois release (provisionally, version 1.102). (2) Cleanup existing non-uppercase "status:" values in the RIPE database Following the Whois release, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase. We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value. As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history). All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP. All changes will be visible in that night's database dump and split files. We expect the cleanup script to take approximately an hour to complete all updates. Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates. Please let me know if you have any questions. Regards Ed Shryane RIPE NCC > On 27 Jul 2021, at 15:59, denis walker wrote: > > Colleagues > > The chairs recognise a consensus to force "status:" values to > uppercase on updates and for the RIPE NCC to perform a one time update > across the database to convert existing "status:" values to uppercase > where necessary. > > We ask the RIPE NCC to go ahead with this process and inform the > community of their implementation plans. > > regards > William & denis > co-chairs DB-WG > > On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg wrote: >> >> Dear colleagues, >> >> In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What >> Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that >> resource "status:" attribute values may not always be all UPPERCASE. >> >> This is because the RIPE database is case-insensitive and case preserving in >> general, meaning a "status:" attribute value is the same regardless of the >> case. >> >> However, this may make parsing this value more difficult as the case should >> be ignored. >> >> Should the DB team implement a rule to always force the "status:" attribute >> value to uppercase, for consistency? >> >> Regards >> Ed Shryane >> RIPE NCC >> >>
Re: [db-wg] "status:" attribute values in the RIPE database
Colleagues The chairs recognise a consensus to force "status:" values to uppercase on updates and for the RIPE NCC to perform a one time update across the database to convert existing "status:" values to uppercase where necessary. We ask the RIPE NCC to go ahead with this process and inform the community of their implementation plans. regards William & denis co-chairs DB-WG On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg wrote: > > Dear colleagues, > > In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What > Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that > resource "status:" attribute values may not always be all UPPERCASE. > > This is because the RIPE database is case-insensitive and case preserving in > general, meaning a "status:" attribute value is the same regardless of the > case. > > However, this may make parsing this value more difficult as the case should > be ignored. > > Should the DB team implement a rule to always force the "status:" attribute > value to uppercase, for consistency? > > Regards > Ed Shryane > RIPE NCC > >
Re: [db-wg] "status:" attribute values in the RIPE database
> It says in the documentation that you cannot split the primary key > attribute value over multiple lines. it's a shame that the NCC does not have a webinar on db use. oh, wait. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: [db-wg] "status:" attribute values in the RIPE database
In message denis wrote: >It says in the documentation that you cannot split the primary key >attribute value over multiple lines. To make sure that is still the >case, I just tried to create this object in the test database: Excellent. I only wish that the folks @ APNIC were as helpful. I tried suggesting to them that their record covering 118.102.134.160/28 was, you know, sub-optimal, but as they often do, they said this isn't their problem and recommended that I go and talk to someone else about the issue, you know, if I really cared about it. If was faster just to program around the problem. Regards, rfg
Re: [db-wg] "status:" attribute values in the RIPE database
Hi Ronald It says in the documentation that you cannot split the primary key attribute value over multiple lines. To make sure that is still the case, I just tried to create this object in the test database: INETNUM: 10.0.0.0 - 10.0.0.255 NETNAME: fred descr: whatever COUNTRY: NL ADMIN-C: dw-test TECH-C:dw-test abuse-c: unr...@ripe.net STATUS:Assigned Pa MNT-BY:AARDVARK-MNT SOURCE:TEST this is the response I got back: Create FAILED: [inetnum] 10.0.0.0 - 10.0.0.255 inetnum:10.0.0.0 - 10.0.0.255 ***Info:Continuation lines are not allowed here and have been removed netname:fred descr: whatever country:NL admin-c:dw-test tech-c: dw-test abuse-c:unr...@ripe.net ***Error: Syntax error in unr...@ripe.net status: ASSIGNED PA ***Info:Value Assigned Pa converted to ASSIGNED PA mnt-by: AARDVARK-MNT source: TEST The important bit is that first info message: ***Info:Continuation lines are not allowed here and have been removed Exactly as it says in the documentation, the pkey split lines have been merged back into a single line separated by single spaces and without causing an error. cheers denis co-chair DB-WG On Tue, 8 Jun 2021 at 23:45, Ronald F. Guilmette via db-wg wrote: > > In message , > Piotr Strzyzewski wrote: > > >On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg > >wrote: > >> inetnum:A1.B1.C1.D1 - > >> A2.B2.C2.D2 > >> > >> My parser wasn't expecting THAT! > > > >That says a lot about the parser, as this is well described in > >documentation: > > Although it may have escaped your attention, as a general matter, reality > frequently diverges from documentation. > > In any case, it is easily possible to parse WHOIS records sufficiently well > to do a multitude of useful things without consulting any documentation > of the format. It can be done just by eyeballing what is fundamentally > a rather simple syntax. > > Furthermore, as I noted, there are literally hundreds of thousands of > objects in the APNIC data base. Of these only a single one had an > inetnum: field that was splattered, needlessly, and for no apparently > good reason, across multiple lines. > > (I hope to soon find out whether such pointless oddities are present > also in the RIPE data base.) > > > Regards, > rfg >
Re: [db-wg] "status:" attribute values in the RIPE database
In message , Piotr Strzyzewski wrote: >On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg wrote: >> inetnum:A1.B1.C1.D1 - >> A2.B2.C2.D2 >> >> My parser wasn't expecting THAT! > >That says a lot about the parser, as this is well described in >documentation: Although it may have escaped your attention, as a general matter, reality frequently diverges from documentation. In any case, it is easily possible to parse WHOIS records sufficiently well to do a multitude of useful things without consulting any documentation of the format. It can be done just by eyeballing what is fundamentally a rather simple syntax. Furthermore, as I noted, there are literally hundreds of thousands of objects in the APNIC data base. Of these only a single one had an inetnum: field that was splattered, needlessly, and for no apparently good reason, across multiple lines. (I hope to soon find out whether such pointless oddities are present also in the RIPE data base.) Regards, rfg
Re: [db-wg] "status:" attribute values in the RIPE database
Ronald F. Guilmette via db-wg wrote on 08/06/2021 00:48: The last time I checked, there was nothing within any of the relevant RFCs that explicity stipulated that the user-id portion of an email address either SHALL or MUST or SHOULD be treated as case insensitive the part of an rfc821/rfc2821 email address has always been case-sensitive. Otherwise, almost all if not all tokens in ripe181++ syntax are case insensitive, and always needed either case translation or case-insensitive comparison to process correctly. Nick
Re: [db-wg] "status:" attribute values in the RIPE database
On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg wrote: > inetnum:A1.B1.C1.D1 - > A2.B2.C2.D2 > > My parser wasn't expecting THAT! That says a lot about the parser, as this is well described in documentation: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/ripe-database-structure/3-8-attribute-values/3-8-1-split-values ;-) Best, Piotr -- Piotr Strzyżewski
Re: [db-wg] "status:" attribute values in the RIPE database
On Mon, Jun 7, 2021 at 4:48 PM Ronald F. Guilmette via db-wg wrote: [...] > P.S. It also complicates parsing... rather needlessly in my view... > to have some field values optionally followed by commentary text > beginning with #. I can't remember now if this was only a problem > I saw with respect to the APNIC data base, or if this sickness has > also infected some RIPE WHOIS records, but if RIPE allows it, I wish > you wouldn't. > > One other small parsing annoyance: Continuation lines. I only saw a > single instance of this and only in the APNIC WHOIS data base, but > it was quite annoying. There was/is a continued line / field value > that looked like this: > > inetnum:A1.B1.C1.D1 - > A2.B2.C2.D2 > > My parser wasn't expecting THAT! These and the case insensitivity are all features defined in RFC 2280 and carried over into its successors. Databases that implement RPSL are likely to have implemented these features as they are part of the specification. To be fair to the authors, there were fewer than 150m Internet users in the world when that original specification was published. Things probably looked quite different! Regards, Leo
Re: [db-wg] "status:" attribute values in the RIPE database
In message , Edward Shryane wrote: >... >However, this may make parsing this value more difficult as the case >should be ignored. > >Should the DB team implement a rule to always force the "status:" >attribute value to uppercase, for consistency? Yes, please. That's a STRONG yes from me. In fact, it would be most helpful if this could be done for ALL field values that are in fact case insensitive, in particular ALL symbolic handles, as well as all country: attributes, etc. Of course, company names and street addresses are best left as they are, as well as all email addresses. (The last time I checked, there was nothing within any of the relevant RFCs that explicity stipulated that the user-id portion of an email address either SHALL or MUST or SHOULD be treated as case insensitive. Thus, some of them may in fact be case sensitive, and thus they should all remain exactly as the parties who put them into the data base wrote them.) Regards, rfg P.S. It also complicates parsing... rather needlessly in my view... to have some field values optionally followed by commentary text beginning with #. I can't remember now if this was only a problem I saw with respect to the APNIC data base, or if this sickness has also infected some RIPE WHOIS records, but if RIPE allows it, I wish you wouldn't. One other small parsing annoyance: Continuation lines. I only saw a single instance of this and only in the APNIC WHOIS data base, but it was quite annoying. There was/is a continued line / field value that looked like this: inetnum:A1.B1.C1.D1 - A2.B2.C2.D2 My parser wasn't expecting THAT!
Re: [db-wg] "status:" attribute values in the RIPE database
>>> +1 to that. I know I would forget that myself 🙂 >> >> except the change is not POLA at all, is it? > > POLA := "principle of least astonishment"? yep randy
Re: [db-wg] "status:" attribute values in the RIPE database
On 07.06.2021 19:13, Randy Bush via db-wg wrote: >>> Agreed, go for the path of least surprises ⇒ enforce case >>> consistency. >> +1 to that. I know I would forget that myself 🙂 > > except the change is not POLA at all, is it? POLA := "principle of least astonishment"?
Re: [db-wg] "status:" attribute values in the RIPE database
>> Agreed, go for the path of least surprises ⇒ enforce case >> consistency. > +1 to that. I know I would forget that myself 🙂 except the change is not POLA at all, is it? randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: [db-wg] "status:" attribute values in the RIPE database
Hi, On Mon, 2021-06-07 at 11:55 +0200, Chriztoffer Hansen via db-wg wrote: > On Mon, 7 Jun 2021 at 11:41, Janos Zsako via db-wg > wrote: > > I agree with Gert. Although it is quite easy to convert the output > > to lowercase or uppercase as > > one wishes, it is also easy to forget about it and be surprised > > about the result. > > Agreed, go for the path of least surprises ⇒ enforce case > consistency. +1 to that. I know I would forget that myself 🙂 Sander signature.asc Description: This is a digitally signed message part
Re: [db-wg] "status:" attribute values in the RIPE database
Thanks, Ed - this: On 07.06.2021 14:24, Edward Shryane via db-wg wrote: > [...] > > I agree, apologies I wasn't clear, by force the "status:" attribute value to > uppercase, I mean that the value should be automatically changed to > all-uppercase, and we should still accept the value in any case. > > Also, we should perform a cleanup on currently inconsistent values (affecting > less than 1% of total inetnum and inet6num objects). entirely clarifies it. ATB, -C.
Re: [db-wg] "status:" attribute values in the RIPE database
Hi Carsten, > On 7 Jun 2021, at 12:57, Carsten Schiefner wrote: > > Ed & all - > > makes sense to me, too. > > However: Instead of forcing this on the creator/updater of an object - > how about the NCC to be as liberal as possible (John Postel's law, the > robustness principle) and to accept any case combination, e.g. "aSSigNED > pi", but very conservatively keep the attribute sored in the DB in > uppercase only? > I agree, apologies I wasn't clear, by force the "status:" attribute value to uppercase, I mean that the value should be automatically changed to all-uppercase, and we should still accept the value in any case. Also, we should perform a cleanup on currently inconsistent values (affecting less than 1% of total inetnum and inet6num objects). Regards Ed > ATB, > > -C. >
Re: [db-wg] "status:" attribute values in the RIPE database
Ed & all - makes sense to me, too. However: Instead of forcing this on the creator/updater of an object - how about the NCC to be as liberal as possible (John Postel's law, the robustness principle) and to accept any case combination, e.g. "aSSigNED pi", but very conservatively keep the attribute sored in the DB in uppercase only? ATB, -C. On 07.06.2021 11:09, Edward Shryane via db-wg wrote: > Dear colleagues, > > In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What > Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that > resource "status:" attribute values may not always be all UPPERCASE. > > This is because the RIPE database is case-insensitive and case preserving in > general, meaning a "status:" attribute value is the same regardless of the > case. > > However, this may make parsing this value more difficult as the case should > be ignored. > > Should the DB team implement a rule to always force the "status:" attribute > value to uppercase, for consistency? > > Regards > Ed Shryane > RIPE NCC
Re: [db-wg] "status:" attribute values in the RIPE database
On Mon, Jun 07, 2021 at 11:09:31AM +0200, Edward Shryane via db-wg wrote: > Should the DB team implement a rule to always force the "status:" attribute > value to uppercase, for consistency? Sounds ok for me. Best, Piotr -- Piotr Strzyżewski
Re: [db-wg] "status:" attribute values in the RIPE database
On Mon, 7 Jun 2021 at 11:41, Janos Zsako via db-wg wrote: > I agree with Gert. Although it is quite easy to convert the output to > lowercase or uppercase as > one wishes, it is also easy to forget about it and be surprised about the > result. Agreed, go for the path of least surprises ⇒ enforce case consistency. -- Chriztoffer
Re: [db-wg] "status:" attribute values in the RIPE database
Dear Ed, Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency? As a DB user, I would find this useful. I agree with Gert. Although it is quite easy to convert the output to lowercase or uppercase as one wishes, it is also easy to forget about it, an be surprised about the result. Best regards, Janos Gert Doering
Re: [db-wg] "status:" attribute values in the RIPE database
Hi, On Mon, Jun 07, 2021 at 11:09:31AM +0200, Edward Shryane via db-wg wrote: > Should the DB team implement a rule to always force the "status:" attribute > value to uppercase, for consistency? As a DB user, I would find this useful. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
