In message <A71ACCE1-3BFB-453A-A9EF-2D8D8FD686C8@ripe.net>, Edward Shryane <eshryane@ripe.net> 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!