Weekly posting summary for ietf@ietf.org

[Thomas Narten]

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

Re: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09

[Bjoern Hoehrmann]

* 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. :

  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

Re: Last Call: (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[Simon Josefsson]

Paul Hoffman  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
> : 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: Last Call: (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[Paul Hoffman]

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 : 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

Last Call: (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[RJ Atkinson]

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: (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[Donald Eastlake]

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  wrote:
> The IESG  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'
>>    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

Re: Last Call: (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[Simon Josefsson]

The IESG  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'
>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