Randy Presuhn | 10 Jan 01:33
Picon

Fwd: RFC Errata Update for Working Group Chairs

Hi -

Updated information on RFC errata ....

Randy
===========================================

From: RFC Editor <rfc-editor <at> rfc-editor.org>
Date: Thu, Jan 8, 2009 at 12:31 PM
Subject: RFC Errata Update for Working Group Chairs
To: wgchairs <at> ietf.org
Cc: RFC Editor <rfc-editor <at> rfc-editor.org>

WG chairs,

We have made some updates to the RFC errata system and would like to
inform you of the new features and explain how these features may
impact your working group.

1) We'd like to bring your attention to the improved search for RFC
errata on http://www.rfc-editor.org/errata.php. You can search by WG
acronym and other information.

Please contact your Area Director if you find errata reports that need
correction.  For example, the Type (Editorial/Technical) may be
incorrect.  Area Directors can log in to verify errata in RFCs
produced by the IETF stream, so if you want to to recommend that a
report be Verified/Rejected/Held, then please let the relevant AD
know. (For the meanings of Status and Type for RFC errata, please see
http://www.rfc-editor.org/status_type_desc.html.)
(Continue reading)

Randy Presuhn | 14 Jan 20:56
Picon

Fw: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

Hi -

Forwarded or your information.

If you'd like to respond or discuss, please do so on the ietf <at> ietf.org list.

Randy

----- Original Message ----- 
> From: "Russ Housley" <housley <at> vigilsec.com>
> To: <wgchairs <at> ietf.org>
> Sent: Wednesday, January 14, 2009 8:00 AM
> Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around
to the Pre-5378 Problem
>

> WG Chairs:
> 
> Please make sure that your WG, and especially your document authors, 
> are aware of this situation.  Please follow the discussion on the 
> IETF Discussion list, and keep the WG informed about the way forward 
> as it develops.
> 
> Thanks,
>    Russ
> 
> 
> >From: "Ed Juskevicius" <edj.etc <at> gmail.com>
> >To: "'IETF Discussion'" <ietf <at> ietf.org>, <ietf-announce <at> ietf.org>,
> >         <iesg <at> ietf.org>, <iab <at> iab.org>, <rfc-editor <at> rfc-editor.org>,
(Continue reading)

Randy Presuhn | 15 Jan 01:48
Picon

Re: [Ltru] Fw: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem

Hi -

In case you haven't been following the discussion,  here's a helpful
distillation by Marshall Eubanks:

The WG Chairs have been asked to make their WG aware of this issue.  
This is a complicated subject, but the executive summary is that if  
you have an Internet-draft that quotes substantially from one or more  
older RFCs (ones with a publication date pre-November 11, 2008), and  
you did not write this earlier work yourself (or you wrote it while  
with another company), you need to be aware of the likely difficulty  
of obtaining RFC5378 clearances for your new work, and also to be  
aware that a work-around is on the way. The work-around should be in  
place to allow submissions to the San Francisco IETF well before the  
normal deadlines.

Again, please direct any followup discussion to ietf <at> ietf.org

Randy

Stephane Bortzmeyer | 23 Jan 08:41
Picon

Re: Moving ahead

On Thu, Dec 18, 2008 at 10:44:30AM +0900,
 Martin Duerst <duerst <at> it.aoyama.ac.jp> wrote 
 a message of 26 lines which said:

> I plan to hand over our drafts to the AD and the IESG around
> December 26th.

Was it done? I do not find it at
<https://datatracker.ietf.org/idtracker/draft-ietf-ltru-4646bis/>

CE Whitehead | 24 Jan 18:13
Picon

Re: Hand-off to AD

Hi.

I am wondering how much longer it will be before the ietf last call for RFC 4646--will it be delayed because the draft's arrival at the IESG has been delayed by RFC5378 clearances requirements?  (It does have to go through an ietf last call still, right?)
 
Thanks.  (I don't mean to sound impatient; just curious)
 
--C. E. Whitehead

 

From: "Doug Ewell" <doug at ewellic.org>
To: "LTRU Working Group" <ltru at ietf.org>
Date: Wed, 3 Dec 2008 19:36:25 -0700 
>>we plan to hand these to our AD in the next few days for consideration by the IESG for publication as RFCs, replacing the current RFC 4645 and RFC 4646.
> I'm delighted to see this day finally come. >>If you spot a "show-stopper" technical problem in either of these, don't hesitate to post it to this list. For any other issues, I strongly suggest holding them for the IETF last call that will (I hope) soon follow. > I have a few, very minor editorial fixes, which I am more than
> happy to hold onto until IETF Last Call.
When is that going to be? Does anyone have any idea at this point? > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14  Best, C. E. Whiteheadcewcathar <at> hotmail.com

Martin Duerst | 25 Jan 10:38
Picon
Gravatar

Fwd: ANNOUNCEMENT: The IETF Trustees invite your comments on revisedproposed legend text to work-around the Pre-5378 Problem

[FYI, just to show everybody that this issue that is blocking us
moving to last call is hopefully moving towards a resolution soon.]

>From: "Ed Juskevicius" <edj.etc <at> gmail.com>

>Subject: ANNOUNCEMENT: The IETF Trustees invite your comments on 
>revisedproposed legend text to work-around the Pre-5378 Problem
>Date: Fri, 23 Jan 2009 00:29:33 -0500

>List-Id: IETF-Discussion <ietf.ietf.org>

>This message is in follow-up to the IETF Trustees' request for community
>review (announced on January 6, 2009) on some new legend text intended to
>help authors work around the "pre-5378 problem".  
>
>Please recall that some I-D authors have experienced difficulty implementing
>RFC5378 since it was published on November 10, 2008.  An example of the
>difficulty is summarized below:
>  - an author wants to include pre-5378 content in a new submission
>    or contribution to the IETF, but
>  - the author is not able to assert that every author of the pre-5378
>    content has agreed (or would agree) to license the earlier material
>    for use outside of the IETF Standards Process
>
>As a result of the above situation, many authors have reported they can not
>submit or progress new contributions, because the legend text authorized by
>the Trustees in November 2008 had no provisions for dealing with this
>"pre-5378" problem. 
>
>The Trustees met with legal counsel on January 22nd to discuss the comments
>and suggestions which you have provided since January 6th.  We have received
>many excellent suggestions for ways to clarify and improve the draft legend
>text, and we are grateful for this.  
>
>Based on the feedback received to date, the Trustees are now proposing a few
>changes to the draft legend text. 
>
>The 'old' legend text (as posted for community review on 2009-01-06) was:
>
>> 6. Text To Be Included in IETF Documents
>> c. Derivative Works and Publication Limitations
>> iii.  If a Contribution includes Pre-5378 Material and the Contributor
>> does not wish to allow modifications of such Pre-5378 Material to be
>> made outside the IETF Standards Process:
>>
>> This document contains material from IETF Documents or IETF Contributions
>> published before November 10, 2008 and, to the Contributor's knowledge,
>> the person(s) controlling the copyright in such material have not granted
>> the IETF Trust the right to allow modifications of such material outside
>> the IETF Standards Process.  Without obtaining an adequate license from
>> the person(s) controlling the copyright, this document may not be modified
>> outside the IETF Standards Process, and derivative works of it may not be
>> created outside the IETF Standards Process, except to format it for
>> publication as an RFC and to translate it into languages other than
>> English.
>
>The updated proposed legend text based on the discussion to date is as
>follows: 
>
>This document may contain material from IETF Documents or IETF Contributions
>published or made publicly available before November 10, 2008. The person(s)
>controlling the copyright in some of this material may not have granted the
>IETF Trust the right to allow modifications of such material outside the
>IETF Standards Process. Without obtaining an adequate license from the
>person(s) controlling the copyright in such materials, this document may not
>be modified outside the IETF Standards Process, and derivative works of it
>may not be created outside the IETF Standards Process, except to format it
>for publication as an RFC and to translate it into languages other than
>English.
>
>The Trustees invite your comments on the updated proposed legend text. We
>believe the updated text incorporates the feedback we have received to date,
>and we hope it clarifies the proposed legend.
>
>The Trustees will meet again in early February to decide on whether to
>revise the Trust License Policy based on the ongoing community discussion.
>If so decided, a revision to the Trust's "Legal Provisions Relating to IETF
>Documents" policy will be published.  Please refer to the attached PDF file
>for an example of how the Legal Provisions document might look if today's
>update to proposed legend text is adopted. A softcopy is available on the
>IETF Trust website under the heading "DRAFT Policy and Procedures Being
>Developed" at:
>http://trustee.ietf.org/policyandprocedures.html 
>
>If you have any comments on the updated proposed legend text, please post
>them before the end of February 7th.  The Trustees need to decide on whether
>to adopt the proposed legend text, and then communicate our decision to you
>on or before February 15th.
>
>Please give this your attention.
>
>Regards,
>
>Ed Juskevicius, on behalf of the IETF Trustees
>edj.etc <at> gmail.com
>
>
>_______________________________________________
>Ietf mailing list
>Ietf <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ietf

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp     
Martin Duerst | 28 Jan 12:46
Picon
Gravatar

Fwd: IAB Response to an Appeal from J-F C. Morfin dd 29 September 2008

FYI (for your information).      Regards,   Martin.

>From: IAB Chair <iab-chair <at> ietf.org>
>To: jefsey <at> jefsey.com, ietf-announce <at> ietf.org
>Subject: IAB Response to an Appeal from J-F C. Morfin dd 29 September 2008 
>Date: Tue, 27 Jan 2009 23:54:11 -0800 (PST)
>List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>

>IAB Response to an Appeal from J-F C. Morfin.
>
>On 29 November 2008 the IAB received an appeal from J-F C. Morfin,
>related to an earlier appeal from Mr Morfin to the IESG that the IESG
>rejected on 29 September 2008.
>
>Mr Morfin's appeal includes significant background material, as well as
>details of the original appeal to the IESG.  In the section "Matter of the
>appeal", Mr Morfin appears to accept the IESG's decision in this specific
>case, and raises a number of points related to it.
>
>The IAB understands the relevant points to be these:
>
>1. The IETF should be watching out for the good of the Internet, and when
>something comes up in that regard -- particularly related to
>interoperability -- it should supersede the charter of a Working Group or
>a decision of a WG chair or an Area Director.
>
>2. Challenges to Working Group deliverables on interoperability grounds
>should never be considered off topic.
>
>3. Some documents should have a "Precaution Considerations" section that
>discusses what precautions have been taken to "preserve present and future
>interoperabilities as well as users' requests".
>
>There does not appear to be anything in the IESG's response to Mr
>Morfin's original appeal that Mr Morfin is directly contesting.  Further,
>the IAB, in reviewing that appeal, finds the IESG's response to be
>correct.  Therefore, the IAB's direct response to this appeal is to
>support the IESG's earlier decision.
>
>Beyond that, the IAB considered Mr Morfin's points:
>
>The IAB considered Mr Morfin's allegation that IETF participants are
>unconcerned with the needs of end users, and found this allegation to be
>baseless and without merit.  To the contrary, the needs of Internet users
>are very important to the IETF, to ensure the relevance of its output, and
>that importance is reflected in IETF processes and practice.  The role of
>the IETF is to provide a venue for individuals working on networking
>hardware or software (whether commercial or free) to get together and
>agree on how those networking devices should interoperate to everyone's
>mutual benefit.  That benefit would not be well served by ignoring the
>needs of users, and producing output that no one wants.
>
>The IAB considered Mr Morfin's allegation that IETF participants are
>insufficiently concerned with interoperability problems that may result
>from their work, and found this allegation to be baseless and without
>merit.  Challenges to the quality and interoperability prospects of
>Working Group deliverables are taken seriously and are generally
>considered to be in scope when they are first raised.  Once decisions are
>made -- usually by rough consensus -- raising the same issues repeatedly
>is not accepted.  This is correct: the Working Group must make progress in
>its work, rather than spend its time revisiting old issues when there's
>nothing new added.  In fact, in the case that prompted this appeal, Mr
>Morfin agrees that the upholding of the Working Group chair's decision was
>proper.
>
>The IAB considered Mr Morfin's allegation that IETF participants are
>unconcerned with supporting multilingual text and the needs of
>non-English-speaking network users around the world, and found this
>allegation to be baseless and without merit.  IETF participants are
>actively working in areas related to multilingual text, enabling more
>multilingual use of the Internet.  As to multilingual participation in the
>IETF: any organization doing the sort of work that the IETF does must have
>a lingua franca in which to work.  Most engineering and scientific
>organizations use English as that language, and it seems best for the IETF
>to do so as well.  It is our judgment that IETF participants generally do
>make a strong effort to understand those whose written or spoken English
>skills are imperfect.  Being a worldwide organization, the IETF welcomes
>engineering contributions from individuals everywhere, both from native
>English speakers and from those for whom English is not the first
>language.
>
>The IAB considered Mr Morfin's allegation that end users are "banned"
>from IETF participation, and found this allegation to be baseless and
>without merit.  The IETF is open to anyone who has access to email and
>makes the effort to participate and contribute, and the IETF welcomes and
>actively encourages participation from any individual who wishes to
>contribute in good faith.
>
>The IAB notes that making a worthwhile contribution does take effort. 
>Showing up unprepared and espousing uninformed opinions takes little
>effort, but such behavior rarely amounts to a useful contribution. 
>Similarly, repeatedly raising the same issues or pursuing a specific
>agenda that differs from that of the Working Group disrupts progress.  To
>safeguard against such disruptive behavior, the IETF has procedures,
>outlined in RFC 3683, for banning a disruptive individual from posting to
>Working Group mailing lists, but this is uncommon, and has only happened
>twice since RFC 3683 was published in March 2004.
>
>
>For the IAB,
>
>--Olaf Kolkman,
>  IAB Chair.
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ietf-announce

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp     

Doug Ewell | 30 Jan 07:08
Favicon

Lowercase language names and the Registry

In the past few days, ISO 639-3/RA has released two updates to their 
code list: a major update on January 20 comprising dozens of changes 
proposed throughout 2008, and a much smaller update on January 26 with a 
couple of additional changes.

All of these changes affect the proposed Registry contents in 
draft-4645bis, and some affect the prose as well.  For example, Section 
2.2 says that sign languages are identified and made into extlangs on 
the basis that the name includes the words "Sign Language."  However, 
with the January 20 changes, ISO 639-3/RA approved a sign language 
called "International Sign" (not "International Sign Language"), which 
means this rule in draft-4645bis needs to be modified slightly.

One change that I think needs to be presented to the WG involves 
lowercase language names.  In previous revisions of ISO 639-3, the 
language code 'fss' had the following name:

    Finnish-Swedish Sign Language

In the January 20 revision, this name was changed slightly and two 
translations were added, as follows:

    Finland-Swedish Sign Language
    Finlandssvenskt Teckenspråk
    Suomenruotsalainen Viittomakieli

As a general rule, we and the ietf-languages group try to avoid adding 
translated language names to the IANA Language Subtag Registry.  The 
Registry is not primarily intended to be a dictionary of language names 
in various languages.  But when these translations are provided as 
official names by the ISO standard, we go ahead and include them.

So far so good, but then the January 26 revision came along and 
lowercased the Finnish and Swedish names, as the requestor originally 
suggested (see http://www.sil.org/iso639-3/cr_files/2008-028.pdf):

    Finland-Swedish Sign Language
    finlandssvenskt teckenspråk
    suomenruotsalainen viittomakieli

The only Description field for a language name in the current LSR that 
begins with a lowercase letter is "tlhIngan-Hol", an additional name for 
Klingon (subtag 'tlh').  Without straying off-topic and getting into the 
sort of flame war that usually accompanies discussions about Klingon, 
this lowercased spelling is generally accepted as the "correct" spelling 
according to the Latin-script orthography for Klingon.

However, I question whether this situation applies to the Finnish and 
Swedish translations above.  With the single exception above, 
Description fields for language subtags normally start with a capital 
letter.  Note that ISO 639-3 already has translated names for other sign 
languages, such as "Catalan Sign Language," and has chosen to spell 
their additional names with an initial capital:

Lengua de señas catalana
Llengua de Signes Catalana

I propose that for draft-4645bis and the Language Subtag Registry 
generally, we introduce a rule that Description fields for language 
subtags be modified from the ISO-provided name if necessary to ensure 
they begin with a capital letter, unless the lowercase letter is 
considered necessary to spell the name correctly (as it is in 
"tlhIngan-Hol").  This is consistent with draft-4646bis, Section 3.1.5, 
which allows Description fields to be "edited or modified" from the ISO 
rendering.

Unless someone objects on-list to this rather pedantic suggestion, it 
will be added to the next draft-4645bis.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Gerard Meijssen | 30 Jan 08:17
Picon

Lowercase language names and the Registry

Hoi,

I have always sadly wondered why the names of languages as spelled in those languages is allowed to be incorrect according to the rules of that language. The only reason that I know is the "history" of a list. A language like Swedish is sverige in Swedish. This list goes on.
Thanks,
      Gerard

2009/1/30 Doug Ewell <doug <at> ewellic.org>

In the past few days, ISO 639-3/RA has released two updates to their code list: a major update on January 20 comprising dozens of changes proposed throughout 2008, and a much smaller update on January 26 with a couple of additional changes.

All of these changes affect the proposed Registry contents in draft-4645bis, and some affect the prose as well.  For example, Section 2.2 says that sign languages are identified and made into extlangs on the basis that the name includes the words "Sign Language."  However, with the January 20 changes, ISO 639-3/RA approved a sign language called "International Sign" (not "International Sign Language"), which means this rule in draft-4645bis needs to be modified slightly.

One change that I think needs to be presented to the WG involves lowercase language names.  In previous revisions of ISO 639-3, the language code 'fss' had the following name:

  Finnish-Swedish Sign Language

In the January 20 revision, this name was changed slightly and two translations were added, as follows:

  Finland-Swedish Sign Language
  Finlandssvenskt Teckenspråk
  Suomenruotsalainen Viittomakieli

As a general rule, we and the ietf-languages group try to avoid adding translated language names to the IANA Language Subtag Registry.  The Registry is not primarily intended to be a dictionary of language names in various languages.  But when these translations are provided as official names by the ISO standard, we go ahead and include them.

So far so good, but then the January 26 revision came along and lowercased the Finnish and Swedish names, as the requestor originally suggested (see http://www.sil.org/iso639-3/cr_files/2008-028.pdf):

  Finland-Swedish Sign Language
  finlandssvenskt teckenspråk
  suomenruotsalainen viittomakieli

The only Description field for a language name in the current LSR that begins with a lowercase letter is "tlhIngan-Hol", an additional name for Klingon (subtag 'tlh').  Without straying off-topic and getting into the sort of flame war that usually accompanies discussions about Klingon, this lowercased spelling is generally accepted as the "correct" spelling according to the Latin-script orthography for Klingon.

However, I question whether this situation applies to the Finnish and Swedish translations above.  With the single exception above, Description fields for language subtags normally start with a capital letter.  Note that ISO 639-3 already has translated names for other sign languages, such as "Catalan Sign Language," and has chosen to spell their additional names with an initial capital:

Lengua de señas catalana
Llengua de Signes Catalana

I propose that for draft-4645bis and the Language Subtag Registry generally, we introduce a rule that Description fields for language subtags be modified from the ISO-provided name if necessary to ensure they begin with a capital letter, unless the lowercase letter is considered necessary to spell the name correctly (as it is in "tlhIngan-Hol").  This is consistent with draft-4646bis, Section 3.1.5, which allows Description fields to be "edited or modified" from the ISO rendering.

Unless someone objects on-list to this rather pedantic suggestion, it will be added to the next draft-4645bis.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


Kent Karlsson | 30 Jan 11:11
Picon

Re: Lowercase language names and the Registry

(for some reason all of the original message text has been turned into a
single paragraph; I'm not going to reedit back the newlines)

I would suggest leaving this alone for 4645bis. I have objected to adding
these translations to 639-3, as 639-3 normally does not provide any
translations. (And I pointed out the inappropriateness of applying the
American English bad habit of "titlecasing" to names in other languages. It
is inappropriate for English as well.) It may also happen that these
translations may disappear in a later revision of 639-3 registry content.

    /kent k

Den 2009-01-30 07.08, skrev "Doug Ewell" <doug <at> ewellic.org>:

> In the past few days, ISO 639-3/RA has released two updates to their 
code
> list: a major update on January 20 comprising dozens of changes 
proposed
> throughout 2008, and a much smaller update on January 26 with a 
couple of
> additional changes.

All of these changes affect the proposed Registry
> contents in 
draft-4645bis, and some affect the prose as well.  For example,
> Section 
2.2 says that sign languages are identified and made into extlangs on
> 
the basis that the name includes the words "Sign Language."  However, 
with
> the January 20 changes, ISO 639-3/RA approved a sign language 
called
> "International Sign" (not "International Sign Language"), which 
means this
> rule in draft-4645bis needs to be modified slightly.

One change that I think
> needs to be presented to the WG involves 
lowercase language names.  In
> previous revisions of ISO 639-3, the 
language code 'fss' had the following
> name:

    Finnish-Swedish Sign Language

In the January 20 revision, this
> name was changed slightly and two 
translations were added, as follows:

> Finland-Swedish Sign Language
    Finlandssvenskt Teckenspråk

> Suomenruotsalainen Viittomakieli

As a general rule, we and the ietf-languages
> group try to avoid adding 
translated language names to the IANA Language
> Subtag Registry.  The 
Registry is not primarily intended to be a dictionary
> of language names 
in various languages.  But when these translations are
> provided as 
official names by the ISO standard, we go ahead and include
> them.

So far so good, but then the January 26 revision came along and
> 
lowercased the Finnish and Swedish names, as the requestor originally
> 
suggested (see http://www.sil.org/iso639-3/cr_files/2008-028.pdf):

> Finland-Swedish Sign Language
    finlandssvenskt teckenspråk

> suomenruotsalainen viittomakieli

The only Description field for a language
> name in the current LSR that 
begins with a lowercase letter is
> "tlhIngan-Hol", an additional name for 
Klingon (subtag 'tlh').  Without
> straying off-topic and getting into the 
sort of flame war that usually
> accompanies discussions about Klingon, 
this lowercased spelling is generally
> accepted as the "correct" spelling 
according to the Latin-script orthography
> for Klingon.

However, I question whether this situation applies to the
> Finnish and 
Swedish translations above.  With the single exception above,
> 
Description fields for language subtags normally start with a capital
> 
letter.  Note that ISO 639-3 already has translated names for other sign
> 
languages, such as "Catalan Sign Language," and has chosen to spell 
their
> additional names with an initial capital:

Lengua de señas catalana
Llengua de
> Signes Catalana

I propose that for draft-4645bis and the Language Subtag
> Registry 
generally, we introduce a rule that Description fields for language
> 
subtags be modified from the ISO-provided name if necessary to ensure 
they
> begin with a capital letter, unless the lowercase letter is 
considered
> necessary to spell the name correctly (as it is in 
"tlhIngan-Hol").  This is
> consistent with draft-4646bis, Section 3.1.5, 
which allows Description fields
> to be "edited or modified" from the ISO 
rendering.

Unless someone objects
> on-list to this rather pedantic suggestion, it 
will be added to the next
> draft-4645bis.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN
> #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.htm
> l
http://www.alvestrand.no/mailman/listinfo/ietf-languages
> –

_______________________________________________
Ltru mailing
> list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


Gmane