In message <a71acce1-3bfb-453a-a9ef-2d8d8fd68...@ripe.net>,
Edward Shryane <eshry...@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!
