Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
For all those people just dying to know about this character (U+19DA), the latest Unicode code chart listing it is here http://www.unicode.org/charts/PDF/U1980.pdf and the name of the character is NEW TAI LUE THAM DIGIT ONE. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Thu, May 26, 2011 at 7:19 AM, Simon Josefsson si...@josefsson.org wrote: The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The Unicode code points and IDNA - Unicode 6.0' draft-faltstrom-5892bis-04.txt as a Proposed Standard Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. If the document updates RFC 5892, in order to remain compliant with the RFCs I would have to modify my implementation and make a backwards incompatible change. Today U+19DA converts to xn--pkf. With this document, I would have to raise an error for that input instead. I believe a case-by-case evaluation for each modified code-point is a good way to determine whether or not to add an exception in the IDNA tables. I haven't seen any discussion why U+19DA is so harmful that it has to be disallowed. On the contrary, everyone appears to agree that the code point is not widely used and the implications of continue permitting it are minor. Thus I would support publication of the document after adding U+19DA to table BackwardCompatible (G) as PVALID. I do realize that I may be in the rough part of the consensus here, which happens, but I want to provide my feedback for the record and allow the decision process to proceed. At least I will be able to shift blame to someone else if/when my users gets confused by this. :-) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
Earlier, John Klensin wrote: I favor the publication of this document with a minimum of further fuss. +1 Character set issues are inherently both very complex and also difficult to reach consensus about. More discussion is not at all likely to reach any different conclusion. It is important to document the conclusion in this case, and to document it on the standards track. Yours, Ran ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
On May 26, 2011, at 4:19 AM, Simon Josefsson wrote: Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. As document co-editor, let me say definitively: this document does *not* update RFC 5892. The filename is an artifact of the early consideration and, as you know, disappears once the document is published as an RFC. Note the information at https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/: this is what the IESG is going on. There is no mention of updates anywhere there. If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. It is always nice to hear support from actual implementers. :-) --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
Paul Hoffman paul.hoff...@vpnc.org writes: On May 26, 2011, at 4:19 AM, Simon Josefsson wrote: Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. As document co-editor, let me say definitively: this document does *not* update RFC 5892. The filename is an artifact of the early consideration and, as you know, disappears once the document is published as an RFC. Note the information at https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/: this is what the IESG is going on. There is no mention of updates anywhere there. Thanks for sharing your view. Earlier discussion suggested that the decision of document status would be punted to the IESG, but it seems they will only make an aggregate decision about the entire document. /Simon If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. It is always nice to hear support from actual implementers. :-) --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
* Doug Barton wrote: IMO one should always expand acronyms the first time they are used. It adds clarity to the text for new readers, and even for old hands it's sometimes necessary to disambiguate recycled TLAs. Some read such suggestions as indicating they should make paragraph-long titles. http://www.rfc-editor.org/rfc-editor/tutorial.latest.pdf: Title * Should be thoughtfully chosen * No un-expanded abbreviations, except for very well known ones (e.g., IP, TCP, HTTP, MIME, MPLS) * We like short, snappy titles, but sometimes we get titles like: An alternative to XML Configuration Access Protocol (XCAP) for manipulating resource lists and authorization lists, Using HTTP extensions for Distributed Authoring and Versioning (DAV) * Choose a good abbreviated title for the running header * WebDAV Alternative to XCAP They should not do that. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 41 messages in the last 7 days. script run at: Fri May 27 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 4.88% |2 | 8.99% |23329 | ron.even@gmail.com 7.32% |3 | 6.46% |16763 | daedu...@btconnect.com 7.32% |3 | 5.39% |13993 | jo...@iecc.com 2.44% |1 | 7.78% |20200 | m...@macchiato.com 4.88% |2 | 4.81% |12487 | ste...@aaa-sec.com 4.88% |2 | 4.73% |12274 | barryle...@computer.org 4.88% |2 | 4.25% |11031 | si...@josefsson.org 4.88% |2 | 3.80% | 9860 | julian.resc...@gmx.de 4.88% |2 | 3.71% | 9615 | adr...@olddog.co.uk 4.88% |2 | 3.60% | 9329 | do...@dougbarton.us 4.88% |2 | 3.15% | 8179 | simon.perrea...@viagenie.ca 2.44% |1 | 4.18% |10839 | hsan...@isdg.net 2.44% |1 | 3.52% | 9122 | john-i...@jck.com 2.44% |1 | 3.50% | 9090 | yaronf.i...@gmail.com 2.44% |1 | 2.89% | 7486 | m...@let.de 2.44% |1 | 2.88% | 7485 | d...@dcrocker.net 2.44% |1 | 2.75% | 7134 | s...@resistor.net 2.44% |1 | 2.67% | 6920 | d3e...@gmail.com 2.44% |1 | 2.48% | 6439 | attila.tak...@ericsson.com 2.44% |1 | 2.28% | 5928 | nar...@us.ibm.com 2.44% |1 | 2.15% | 5588 | ned+i...@mauve.mrochek.com 2.44% |1 | 1.94% | 5021 | derhoe...@gmx.net 2.44% |1 | 1.93% | 5010 | nit...@juniper.net 2.44% |1 | 1.88% | 4883 | rja.li...@gmail.com 2.44% |1 | 1.80% | 4672 | terry.mander...@icann.org 2.44% |1 | 1.80% | 4666 | paul.hoff...@vpnc.org 2.44% |1 | 1.71% | 4431 | b...@nostrum.com 2.44% |1 | 1.57% | 4078 | m...@sap.com 2.44% |1 | 1.40% | 3623 | j...@mercury.lcs.mit.edu +--++--+ 100.00% | 41 |100.00% | 259475 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-dnssec-registry-fixes-08.txt (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry' draft-ietf-dnsext-dnssec-registry-fixes-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dnsext-rfc2672bis-dname-22.txt (Update to DNAME Redirection in the DNS) to Proposed Standard
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Update to DNAME Redirection in the DNS' draft-ietf-dnsext-rfc2672bis-dname-22.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
