Talk:Punycode

message: Is Punycode patented? --84.61.51.126 13:01, 6 July 2006 (UTC)
replies: text: Nobody's asserted a patent against it as far as I know. Given the nature of the patent system, that's the most anyone can say for certain. --Alvestrand 15:07, 18 October 2006 (UTC)
thread_title:  Patent issues 

message: From the text its not really clear about how exactly you get back to the name and even if its possible. Or how the position of the character is encoded. Since currently it looks to me as if "bücher" "bächer" "bchüer" etc. all get the same bcher-kva code??
:I've rewritten the first part of the encoding description based on reading the rfc, more work is still needed though. Plugwash 01:45, 27 February 2007 (UTC)
replies: text: Someone more knowledgable than I should explain why the non-ascii character "ü" being insertes at various places WITHIN an ascii string magically transmutes to "ý" if it is inserted BEFORE the string.  It all sound like an obfuscation of alchemy to me.   —Xojo  (talk)  01:42, 3 September 2010 (UTC)
replies: text:  Oh, that's just because "ý" (U+00FD) is the next code point after "ü" (U+00FC). No alchemy there! — Sebastian 07:13, 20 December 2011 (UTC)
thread_title:  Examples 

message: The heading "Encoding procedure" says:
"The 'bücher' example given above . . ."
There is no "bücher" example "above" in the current form of the article.
This is probably an editorial anomaly in the wake of rearrangement of the article.
Le crayon rouge ne dort jamais.
Doug Kerr 17:56, 11 March 2007 (UTC)
replies: text: I've reworded it. --Zundark 10:42, 12 March 2007 (UTC)
thread_title:  Encoding principles example 

message: 'Bootstring' redirects here, even though it doesn't strike me as synonymous to 'Punycode' (Punycode, going by the title of ref1, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA), seems to be a kind of Bootstring).
Could someone with more knowledge on the matter either create a Bootstring article describing what that is or make it clear that Bootstring indeed is merely a synonym? I'm curious which/what it is.
-pinkgothic (talk) 12:42, 12 November 2010 (UTC)
replies: text: The section "Encoding of non-ASCII character insertions as code numbers" needs a complete rewrite. Someone went out of their way to use computer science jargon. 188.103.59.142 (talk) 16:24, 9 September 2011 (UTC)
thread_title:  Bootstring 

message: Section Separation of ASCII characters says "Since it is a basic character, the ASCII hyphen may still appear in the string before this additional character, but the addition does not cause ambiguity". But precisely because the hyphen may still appear, we have a problem: Suppose you wanted to convert the string "bcher-kva" to a label - wouldn't that be just the same, thus rendering the label "bcher-kva" ambiguous? — Sebastian 07:19, 20 December 2011 (UTC)
replies: text: The description appears to be incorrect: a hyphen is always added (unless there are no basic characters at all) so "bcher-kva" would be encoded as "bcher-kva-". See example (S) in RFC 3492. (But in practice Punycode is hardly used outside of IDNA, and IDNA wouldn't apply Punycode to such a string anyway.) I've undone 195.242.190.233's changes of 17 November 2010, which introduced the error. --Zundark (talk) 09:58, 20 December 2011 (UTC)
replies: text:  Thanks! — Sebastian 10:28, 20 December 2011 (UTC)
thread_title:  Ambiguity in separation of ASCII characters 

message: The current link to the Punycode RFC didn't work; it was redirected to an IETF home page.  <https://www.rfc-editor.org/rfc/rfc3492.txt> is the new link to the Punycode RFC.  — Preceding unsigned comment added by CTMacUser (talk • contribs) 06:37, 14 March 2019 (UTC)
thread_title:  The RFC Website Has Changed 

message: Anyone know 179.98.225.10 (talk) 14:36, 16 March 2019 (UTC)
replies: text: Do you have a source? Your comment here was just cited in a Stack Exchange Q&A. If we had a reputable source, I could add this info both to the Q&A and to the Wikipedia article. Maxlaumeister (talk) 23:34, 26 June 2020 (UTC)
replies: text:  It seems to be so obvious that nobody said it explicitly. Even the Wiktionary article on Punycode just says "Blend of puny + Unicode" under etymology, but without any source. Someone could perhaps ask Adam M. Costello, the inventor of Punycode, personally. He seems like a really nice guy. But asking him doesn't directly give us a reference, unless the question is answered publicly on the internet somehow. --Jhertel (talk) 22:19, 28 June 2020 (UTC)
replies: text:  I just emailed Adam directly and published an article on my blog with our exchange. He mentioned three specific ways that he believes it's "puny"; he didn't mention "pun" at all. I'll let someone else determine how best to incorporate this info into Wikipedia. Maxlaumeister (talk) 20:32, 18 July 2020 (UTC)
thread_title:  WHY IS IT CALLED PUNYCODE? 

message: What will happen if the number of states to be skipped will get larger than 1.03e40=35*34*...*2? Unlikely given the application, but there is no answer given inside the article, as far as I've understood. Am I correct?  — Preceding unsigned comment added by 212.82.199.28 (talk) 15:40, 9 December 2019 (UTC)
thread_title:  Limited to 35! 

message: I must admit that I understand very little of this article, especially because there are almost no examples. What I especially miss is how to encode pure basic ASCII strings in Punycode. It only seems to focus on strings that include at least one non-ASCII character, probably because Punycode was created specifically for handling this subset of Unicode strings. But I would assume that Punycode is also able to encode pure basic ASCII strings? At least, that's what the first sentence in the article claims: "Punycode is a representation of Unicode", which means it can handle all strings including basic ASCII strings which is a subset of all Unicode strings. If that is the case, how does it do that? For instance, what is the Punycode encoding of "London"? My guess is that it would be "London", but I can't find that information in the article; the section "Separation of ASCII characters" seems to say that "London" would be encoded as "London-" ("If any characters were copied, an ASCII hyphen is added to the output"), but I find that quite odd. Also, what is the encoding of the empty string? Is it the empty string? Simple examples are needed, preferably a table that especially lists both very common cases like pure basic ASCII strings ("a", "abc", "London", "A string with spaces" if a space is a basic ASCII character) as well as corner cases like the empty string (""), the string "3", the string "-", and a string consisting of a single non-basic ASCII letter such as "ü".
As a first step, though, I would simply add the example of "London" next to the mentioned example of München. But I still don't know the Punycode encoding of "London". I can't even use an online Punycode converter to figure it out, as those I have tried all seem to get it wrong, as they all add "xn--" in the beginning of encodings of non-ASCII strings, which does not seem to be part of Punycode (they seem to mistakenly mix in Nameprep, which is not part of Punycode, in the process). 
--Jhertel (talk) 16:11, 15 February 2020 (UTC)
thread_title:  More examples are needed, especially pure ASCII examples and corner cases 

message: So, technically, this means that https://xn--xn--wikipedia--.org redirects to https://xn--wikipedia-.org and then to https://wikipedia.org because the conversion method still works even if the original domain is LDH? 154.5.234.189 (talk) 04:55, 17 November 2020 (UTC)
thread_title:  Wait a moment… 

message: Maybe the section `Encoding of non-ASCII character insertions as code numbers` should have the hard to follow text that describes the state changes removed, and instead have a proper state machine as a formal definition with a state graph inserted and/or just pseudo code? Explaining it in plain English was worth a try, but I can only surmise that sadly I feel like it didn't really succeed. At least for me it isn't really possible to decipher from the text how the encoding actually works. 2003:EA:7F11:DE00:BC43:6BFF:FE40:1BA5 (talk) 12:38, 17 December 2020 (UTC)
thread_title:  Section "Encoding of non-ASCII character insertions as code numbers" needs revamp