How do I create a HTML link to an emergency number like 911 or 112?
The RFC says
The
phone number can be represented in either global or local
notation. All phone numbers MUST use the global form unless they
cannot be represented as such.
[Emergency numbers ("911", "112")] cannot be represented in global form and
need to be represented as a local number with a context.
From the local-context section I don't find it easy to understand what a "local-context" is, let alone what the correct one for this case is. It lists domain prefixes like houston.example.com or a numeric prefix like +1, and in one paragraph it says
A context consisting of the initial digits of a global number does
not imply that adding these to the local number will generate a valid
E.164 number. It might do so by coincidence, but this cannot be
relied upon. (For example, "911" should be labeled with the context
"+1", but "+1-911" is not a valid E.164 number.)
But the phrasing of this paragraph is again very confusing.
Is
112
now the correct way of doing it, and the fact that it is not a valid E.164 number is irrelevant?
Or is the fact that it is not a valid E.164 number a problem?
In some other places I see people using
112
And again other people recommend
112
But when I tap that link on Android, the dialer opens with the number
112;746632668398+49
The cited Section 5.1.5 the RFC states
A context consisting of the initial digits of a global number does
not imply that adding these to the local number will generate a valid
E.164 number. It might do so by coincidence, but this cannot be
relied upon. (For example, "911" should be labeled with the context
"+1", but "+1-911" is not a valid E.164 number.)
I interpret this that emergency numbers should be prefixed by their country-secific prefixes, i.e.
in the US, 911 should be used as 911
in Germany 112 should be used as 112
The rest of the paragraph is about this syntax not being compliant to the E.164 recommendation. As far as I understand, E.164 is irrelevant in this context though.
Related
I have a dataset containing obfuscated IPs. In order to do something, I would need to match IPs I know with this dataset.
If my dataset contains hashed IPs 1053617334, 1043615471
And I have IP 192.168.0.1, how can I hash it so I can verify if it is in the dataset or not?
IPv4 addresses are commonly represented as so-called "dotted quads", like 192.0.2.42 or 192.168.0.1.
That's 32 bits of data. And, that same data can be represented as a single unsigned decimal number. Your numbers like 1053617334, 1043615471 are probably examples of those numbers. They aren't, strictly speaking, hashed or obfuscated. They're just represented differently.
http://192.168.0.1 and http://3232235521 mean exactly the same thing.
There are all sorts of online tools to convert back and forth between dotted quad and decimal representation. For example.
Consult your AA documentation or support team to figure out how to handle this.
In two's-complement notation, there's always an odd-man-out value to compensate for the 0/origin value that is conceptually neither positive nor negative. We treat 0 as positive for the sake of pragmatism, and we treat its counterpart, which is a 1 in the top bit and 0 in the rest, as negative, but conceptually, they are both special values that have no sign, because in both cases, -v==v.
For instance, in a signed 32-bit value, this number might be represented in one of these based forms:
0b10000000000000000000000000000000
0x80000000
-2147483648
I've personally been using my own term for this odd value for a while, which I will share below as my own answer, and let you all decide whether it's worthy, but I wouldn't be surprised if there's already an accepted name for it.
I leave the rest to you...
Edit: On further research, I did find some sites claiming that "it is sometimes called the weird number", but these blurbs are consistently copied verbatim from a Wikipedia entry on two's complement notation, which itself only references a 2006 college research paper that's unavailable at the given location, but I found here, where it's only referred to in passing as such. Wikipedia also references a single book, but that book's usage appears to be based on the text of the Wikipedia entry, which existed before the book was written. I'm not convinced that anyone other than one University of Tokyo student ever called it "the weird number" in practice.
Depending on context, I might refer to it neutrally as the dead value or, if I'm feeling like anthropomorphizing it, I call it Death. I think of that lone top bit as a scythe of sorts.
I call it this for two reasons:
On the ring that is two's-complement notation, its counterpart is 0, which we commonly refer to as the origin. One antonym for origin is death.
This particular value, being ambiguous as it is, tends to catch out a lot of programmers. It is literally the death of a lot of unsuspecting algorithms.
When writing terse assembly, I tend to abbreviate it as just "D", for instance if I had a condition that was satisfied by all values greater that zero, and Death, I might call the flag "GZD".
I simply call that the minimum integer or minimum value, since that is indeed what it is in two's complement.
It's also described that way in the C standard limits.h (and C++ equivalent) header, such as with SCHAR_MIN, INT_MIN, LONG_MIN and so on.
For card payments we accept a security code of 3 digits.
In some instances on some browsers (likely to be older IE versions) we have had occurences of a code with a 0 at the start (example 012) having the first 0 removed thus only allowing the input of 12. This therefore invalidates the security code.
We have this as a number input to allow number input only on mobile devices, I've a feeling this is the cause. However, is there anything we can do to stop this from happening?
The current input code is:
<input type="number" pattern="[0-9]*" size="4" value="$securitycode" name="securitycode">
Many thanks in advance.
This behavior is according to the spec, so I don't think you can directly do something to prevent it.
If the user agent provides a user interface for selecting a number,
then the value must be set to the best representation of the number
representing the user's selection as a floating-point number.
Specifically, the smoking gun in the definition of "best representation" is
(11). Collect a sequence of characters that are ASCII digits, and interpret the resulting sequence as a base-ten integer. Multiply value
by that integer.
I am assuming that you want to keep the input type so that mobile user agents present to the user a UI better suited to the task of inputting a numeric code. So what you can do is, since you now know what the spec says, anticipate this behavior on the server side: pad the incoming value with zeroes.
It seems changing the input type to "text" might resolve this issue.
I went to my bank website the other day and entered my account number with a trailing space. An error message popped that said, "Account number must consist of numeric values only." I thought to myself, "Seriously?! You couldn't have just stripped the space for me?". If I were any less of a computer geek, I may even have thought, "What? There are only numbers in there!" (not being able to see space).
The Calculator that comes with Ubuntu on the other hand merrily accepts spaces and commas, but oddly doesn't like trailing dots (without any ensuing digits).
So, that begs the question. Exactly how forgiving should web forms be? I don't think trimming whitespace is too much to ask, but what about other integer fields?
Should they allow +/- signs?
How many spaces should be allowed between the sign and the number?
What about commas for thousands separators?
What about in other parts of the world where use dots instead?
What if they're in between every 4 digits instead of every 3?
What about hexidecimal and octal representations?
Scientific notation?
What if I accidentally hit the quote button when I'm trying to hit enter, should that be stripped too?
It would be very easy for me to strip out all non-digit characters, and that would be extremely forgiving, but what if the user made an actual mistake that affects the input and should have been caught, but now I've just stripped it out?
What about things like phone numbers (which have a huge variety of formats), postal codes, zip codes, credit card numbers, usernames, emails, URLs (should I assume http? What about .com while I'm at it?)?
Where do you draw the line?
For something as important as banking, I don't mind it complaining about my input, especially if the other option is mistakenly transferring a bucketload of money into some stranger's account instead of my wife's (because of a missing or incorrect digit for example).
A classic example is one of my banks which disallows monetary values unless they have ".99" at the end (where 9 can be any digit of course). The vast majority of things I do are for exact dollar amounts and it's a tad annoying to have to always enter 500.00 instead of just 500.
But I'll be happier about that the first time I avoid accidentally paying somebody $5072 instead of $50.72 just because I forgot the decimal point. Actually, that's pretty unlikely since it also asks for confirmation and I'm pretty anal in controlling my money :-)
Having said that, the general rule I try to follow is "be liberal in what you accept, be strict in what you produce".
This allows other software using my output to expect a limited range of possibilities (making their lives easier). But it makes my software more useful if it can handle simple misteaks.
You draw the line at the point where the computer is guessing at what the correct input should be.
For example, a license key input box I wrote once accepts spaces and dashes and both upper and lower case, even though internally the keys were without said spaces, dashes and were all upper case. I could do that, since I knew that none of the keys actually had spaces or dashes.
Your example about URLs is another good one. I've noticed that modern browsers (I'm using Chrome), when something like 'flowers' is typed into the address bar, it knows it should search for it since it's not a valid URL. If instead, I type 'st' it auto corrects (or auto-suggests) 'stackoverflow.com' since it's a bookmark.
A well-written input system will complain when it would otherwise be forced to guess what the correct input should be.
Numeric input:
Stripping non-digits seems reasonable to me, but the problem is conflicting decimal notation. Some regions expect , (comma) to denote the decimal separator, while others use . (period). Unless the input would likely be in other bases, I would only assume base 10. If it's reasonable to assume non-base 10 input (base-16 for color input, for example), I would go with standard conventions for denoting the bases: leading 0 means base 8, leading 0x means base 16.
String input:
This gets a lot more complicated. It mostly depends on what the input is actually meant to represent. A username should exclude characters that will cause trouble, but the meaning of 'cause trouble' will vary depending on the use of the application and the system itself. URLs have a concrete definition of what qualifies, but that definition is rather broad. Fortunately, many languages come with tools to discern URLs, without you having to code your own parsing (whether the language does it perfectly or not is another question).
In the end, it's really a case-by-case basis. I do like paxadiablo's general rule, though: Accept as much as you can, output only what you must.
It totally depends on how the data is going to be used.
If the input is a monetary amount, for a transaction for example, then the inputted variable should be normalised to a set of standards for sure.
If it's simply a case of a phone number, then it is unlikely the stored data will provide any functional sort of use so you can be more forgiving.
There is nothing wrong with forcing correct format to make displayed look nicer, but you have to balance user irritation with micro benefits.
Once you start collecting data you can scan through it and see what sort of patterns emerge, and you can auto strip off inputted format.
Where do you draw the line?
When the consequences of accepting "invalid" data outweigh the irritation of not accepting it.
Should they allow +/- signs?
If negative values are valid, then of course they should.
If not, then don't just silently strip minus signs, as it totally changes the meaning of the data. Stripping pluses is less of a problem.
What if [thousands separators are] in between every 4 digits instead of every 3?
In countries that use three-digit grouping, "1,0000" can be assumed to be a typo. But is it a typo for "10,000" or for "1,000"? I wouldn't dare guess, as a wrong guess could cost the user $9,000.
What about hexidecimal and octal
representations?
Unless you're running the search feature for unicode.org, I can't imagine why anyone would use hexidecimal in web form.
And "01234" is almost certainly intended to be 1234 instead of 668.
What about things like...credit card numbers
Please allow spaces or hyphens in credit card numbers. It's really annoying when I have to type an undelimited 16-digit number.
I think you're over reacting a little bit. If there's anything in the field that shouldn't be there, strip it. otherwise try to force the input into whatever format you want, and if it doesn't fit, reject it.
I would say "Accept anything but process only valid data".
Expect your users to behave like a computer noob. Validate the input data using regular expressions and other validators.
Search for standard regular expressions for urls, emails and stuff.
Throw in a regular exp like this "/(?:([a-zA-Z0-9][\s,]+))([a-zA-Z0-9]+)$/" for comma or space separated values. With minor tweaking this exp will work for any number of comma separated values.
The one that irritates me as a user is credit card numbers, conventionally these appear as groups of 4 digits with spaces separating them but the odd webform will only accept a single string of digits with no spaces and no indication that this is the format it's seeking. Similarly telephone numbers, humans often use spaces to improve clarity, webforms sometimes accept the spaces and sometimes don't.
I've seen binary and hex used quite often but never octal. Yet octal has it's own convention for being used in some languages (ie, a leading 0 indicating octal base). When is octal used? What are some typical situations when one would use octal or octal would be easier to reason about? Or is it merely a matter of taste?
Octal is used when the number of bits in one word is a multiple of 3, or if the grouping of the bits makes sense to notate in groups of 3. Examples are
ancient systems with 18bit word sizes (mostly historical)
systems with 9bit bytes (mostly historical)
unix file permissions with 9bits (3*3bits, "rwxr-x---" 0750)
unix file permissions with 12bits (the same as the 9bit version but adding three bits in front for setuid, setgid, and sticky, 01777 but the letters are more complicated here)
I have not encountered any uses of octal other than unix file permission bits during my about 25 years in IT.
If the number of bits in your word is a multiple of 4, however, please do use hex, by all means.
Octal is used as a shorthand for representing file permissions on UNIX systems. For example, file mode rwxr-xr-x would be 0755.
Octal is used when the syntax is a relic from the ages when it perhaps made sense on some platform (system words haven't always been a multiple of 8 bits). Nowadays hex is the thing to use.
Didn't think of this but Digital displays!
Several other uses from:
http://en.wikipedia.org/wiki/Octal
One of the main reasons octal used to be more frequently used was that it is easier to convert between octal and binary in your head than hex to binary: you only have to remember the binary representation of the 8 octal digits (0-7).
Back in the days when debugging meant reading register contents from a row of LEDs, or entering data with an array of toggle switches, this was a big concern. The panels on many of these early computers grouped the LEDs and switches in groups of threes to facilitate this.
However, hex began to win out as word sizes that are multiples of 8-bit bytes began to win out, and the need to read and enter data in binary became unecessary (with console text UI and later GUI debuggers).
If birds could count, my guess would be that they use octal. While most birds have 3 digits on their feathered "hands", most are Tetradactyly, meaning 4 toes on each foot.
In avionics, ARINC 429 word labels are almost always expressed in octal.
Music, as long as you stay away from (most) sharps and flats.
FYI, there are a few places that windows and javascript automatically decide that a number prefixed with a zero is octal and convert the number.
In windows if you ping and address like 10.0.2.010 it will actually ping 10.0.2.8
Windows also does this if you enter it as the ip/dns address for the computer
Though it is deprecated, Javascript does this by default on some functions like parseInt if you do not specify a radix http://www.w3schools.com/jsref/jsref_parseint.asp