Re: Results of Duplicate Busters Survey #1

Fw: IETF Mailing List Issue

Hi -

Forwarded for your information.

Randy (as list admin)

-----Forwarded Message-----
>From: Alexa Morris <amorris <at> amsl.com>
>Sent: Sep 5, 2008 12:02 PM
>To: "ietf-announce <at> ietf.org" <ietf-announce <at> ietf.org>
>Cc: Working Group Chairs <wgchairs <at> ietf.org>, IETF Discussion <ietf <at> ietf.org>, The IESG <iesg <at> ietf.org>
>Subject: IETF Mailing List Issue
>
>Last night, after a server reboot, the postconfirm spam checker that was
>recently put in front of IETF mailing lists failed to start.  Unfortunately,
>this resulted in a huge influx of spam to the IETF ticket system, and a
>simultaneous failure of IETF list email. Everything is back online now and
>functioning; however, email messages sent to IETF lists in the last 16 hours
>were lost, and will need to be resent.
>
>We have now installed a direct watcher on postconfirm, to force a restart of
>it when it fails. In addition, Henrik is working on the system now to find
>out why it failed to start in the first place, and why its failure caused
>mail loss rather than mail deferral.
>
>I apologize for any inconvenience this may have caused you. As always,
>please feel free to contact me if you have any questions or concerns.
>
>Regards,
>Alexa
>
>-----------
>Alexa Morris / Executive Director / IETF
>48377 Fremont Blvd., Suite 117, Fremont, CA  94538
>Phone: +1.510.492.4089 / Fax: +1.510.492.4001
>Email: amorris <at> amsl.com
>
>Managed by Association Management Solutions (AMS)
>Forum Management, Meeting and Event Planning
>www.amsl.com <http://www.amsl.com/>
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ietf

Re: Registry updated

> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of
> Doug Ewell


> I encouraged Gérard to move this thread onto the WG, since he was
> presenting proposals and suggestions for BCP 47 to a hand-picked
> private list.

If one or more proposals are to be discussed, it would help to have them clearly stated, and with clear
indication of if and how they relate to the current charter.


> 1.  One of the numerous objections to the use of ISO 3166-2 code
> elements as sub-region subtags is that the list is not freely
> available.
> If it is true that the codes may become freely available in the future,
> that does remove one of the objections, although the others remain.

This looks like a discussion regarding one or more potential proposals for a 4646ter, not a specific
proposal that's in scope for 4646bis.


> 2.  The discussion about Europanto and "Neglish" probably belongs on
> ietf-languages rather than here, but I wasn't about to tell Gérard to
> take his thread to two different lists.

In this case, you should have, IMO. It doesn't belong here.


> 3.  The lengthy historical section was probably meant to establish a
> relationship between AFNOR XP Z 44-020, "Code for the representation of
> names of Oceans and Seas," and the other ISO standards we use in BCP
> 47.
> I suppose the ultimate purpose was to show that we should add region
> subtags for non-land areas of the earth.

Again, this looks like a discussion regarding one or more potential proposals for a 4646ter, or perhaps
regarding potential requests to register certain variant subtags, but not a specific proposal that's in
scope for 4646bis.


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

Re: Registry updated

Peter Constable <petercon at microsoft dot com> wrote:

>> 2.  The discussion about Europanto and "Neglish" probably belongs on 
>> ietf-languages rather than here, but I wasn't about to tell G?rard to 
>> take his thread to two different lists.
>
> In this case, you should have, IMO. It doesn't belong here.

Thanks to Peter, as well as others who replied semi-privately, for 
taking me out behind the woodshed on this.

Gérard had sent a list of discussion items to a hand-picked list of 
recipients.  Most of the items (other than railing against the inclusion 
of Europanto in Ethnologue and ISO 639-3) seemed to be relevant to one 
list or another.

Even though we're ridiculously behind schedule (as I've often complained 
while the rest of the list stays silent for weeks), and Gérard's items 
are all outside our current scope, I thought it would be better to have 
Gérard bring them here and have the list comment on them than to keep 
the thread private.  I guess I thought some of his items, even the ones 
I disagree with, might be suitable for discussion in a future project, 
and there is no "4646ter" list where such people can go today.

I guess next time someone brings their LTRU-ish issues to me privately, 
instead of pointing them to a list where they will have a proper 
audience, and risk taking some of the flak myself, I'll just tell them 
to go pound sand or something.

Frustrated,

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

Re: Results of Duplicate Busters Survey #2

Forwarded from ietf-languages.  The survey was presented to both lists.

> From: Michael Everson <everson <at> evertype.com>
> Subject: Re: Results of Duplicate Busters Survey #2
> To: ietflang IETF Languages Discussion <ietf-languages <at> iana.org>
> Message-ID: <1F9C1C93-67EE-4BDA-81B5-7E84B0935A95 <at> evertype.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On 7 Sep 2008, at 01:18, Peter Constable wrote:
>>> Frank Ellerman wrote:
>>> IMO decreeing that RFC 4646 and older tags are obsoleted
>>> by whatever ISO 639-3 says is no option.  There will be
>>> applications limiting themselves to RFC 4646 languages,
>>> all ISO 639-1/2 warts included.  Interpreting such tags
>>> as defined in ISO 639-3 can result in unclear gibberish.
>>
>> Alpha-3 language IDs that are in ISO 639-2 and the alpha-3
>> counterparts to alpha-2 IDs in ISO 639-1 represent the same
>> semantics in ISO 639-3 as the items in ISO 639-1/-2.
>
> I've heard enough, thank you all. My ruling (because Doug asked me to
> rule on this) is that the ISO 639-3 field should be sufficient. We do
> not need to repeat ISO 639-2 fields and we do not need to repeat ISO
> 639-1 fields. 639-3 is a proper superset, and is more accurate than
> the others.
>
> If anyone wants to make this all tidier, they should talk to the 639
> Registration Authorities and ask them to harmonize their fields. It is
> not our job to do that here.
>
> Doug, make it so.
>
> Michael Everson * http://www.evertype.com

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

FW: Nomcom call for candidates

Hi -

Please consider serving.

Randy

> From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On
> Behalf Of ext NomCom Chair
> Sent: Friday, September 12, 2008 6:48 PM
> To: Working Group Chairs
> Subject: Nomcom call for candidates 
> 
> The message below was just sent to the IETF-Annoucne list.
> However, it order to get to as many people as possible, I am asking WG
> chairs a favor.  Please forward the message to your working groups.
> 
> Thank you,
> Joel M. Halpern
> 
> The 2008-9 IETF Nominating Committee needs your help.
> We have started getting candidates.
> If we are going to do our job in time, we have only 3 more weeks to get
> enough candidates to have a reasonable pool for all the jobs.
> At the moment, we do not have a reasonable pool for any jobs.
> 
> If you are willing to serve, please nominate yourself.
> If there is someone you think would do a good job, please nominate them.
> 
> The web site at:
>     http://wiki.tools.ietf.org/group/nomcom/08
> Has the list of positions we are seeking people for, as well as tools
> for
> providing both nominations and feedback.
> 
> Alternatively, you can submit nominations by sending email to me.
> 
> Please help us.
> 
> Thank you,
> Joel M. Halpern
> jmh <at> joelhalpern.com
> nomcom-chair <at> ietf.org

Fw: 73rd IETF - WG Scheduling - CUTOFF SEPT. 15

Hi -

There are currently no plans for lru to meet at IETF 73.
If you believe a face-to-face meeting would be useful, please
send specific agenda proposals to the ltru <at> ietf.org mailing list
as soon as possible.

Randy
ltru co-chair

> From: "IETF Agenda" <agenda <at> ietf.org>
> To: "Working Group Chairs" <wgchairs <at> ietf.org>
> Cc: <irsg <at> isi.edu>; <bofchairs <at> ietf.org>
> Sent: Friday, September 12, 2008 6:42 AM
> Subject: 73rd IETF - WG Scheduling - CUTOFF SEPT. !5 
>
> REMINDER: Cutoff for submitting Working Group scheduling requests is
> Monday, September 15 at 17:00 PDT (24:00 UTC/GMT).
> 
> https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi
> 
> -----------------------------------------------------------------
> 73rd IETF  Minneapolis, MN, USA
> Meeting Dates: November 16-21, 2008
> Host: Google
> -----------------------------------------------------------------
> IETF meetings start Monday morning and run through Friday mid-afternoon
> (15:15).
> 
> We are accepting scheduling requests for all Working Groups and BOFs
> starting.  The milestones and deadlines for scheduling-related activities
> are as follows:
> 
> NOTE: cutoff dates are subject to change.
> 
> September 15, Monday - Cutoff date for requests to schedule Working Group
> meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00
> UTC/GMT). 
> September 29, Monday - Cutoff date for requests to Area Directors to
> schedule BOFs at 17:00 PDT (24:00 UTC/GMT). 
> October 6, Monday - Cutoff date for Area Directors to approve BOFs at
> 17:00 PDT (24:00 UTC/GMT). 
> October 10, Friday - Preliminary agenda published for comment.
> October 22, Wednesday - Cutoff date for requests to reschedule Working
> Group and BOF meetings 17:00 PDT (24:00 UTC/GMT).
> October 27, Monday - Final agenda to be published. 
> November 5, Wednesday - Draft Working Group agendas due by 17:00 PT (01:00
> Thursday, November 6 UTC/GMT).
> November 10, Monday - Revised Working Group agendas due by 17:00 PT (01:00
> Tuesday, November 11 UTC/GMT).
> 
> Submitting Requests for Working Group and BOF Sessions
> 
> Please submit requests to schedule your Working Group sessions using the
> "IETF Meeting Session Request Tool," a Web-based tool for submitting all
> of the information that the Secretariat requires to schedule your
> sessions.
> 
> The URL for the tool is:
> 
> https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi
> 
> Instructions for using the tool are available at:
> 
> http://www.ietf.org/instructions/session_request_tool_instruction.html
> 
> Please send requests to schedule your BOF sessions to agenda <at> ietf.org. 
> Please include the acronym of your BOF in the subject line of the message,
> and include all of the information specified in item (4) of "Requesting
> Meeting Sessions at IETF Meetings" in the body.  (This document is
> included below.)
> 
> Submitting Session Agendas
> 
> For the convenience of meeting attendees, we ask that you submit the
> agendas for your Working Group sessions as early as possible.  Draft
> Working Group agendas are due Wednesday, November 5 by 17:00 PDT (01:00
> Thursday, November 6 UTC/GMT).  Revised Working Group agendas are due no
> later than Monday, November 10 at 17:00 PDT (01:00 Tuesday, November 11
> UTC/GMT).  The proposed agenda for a BOF session should be submitted along
> with your request for a session.  Please be sure to copy your Area
> Director on that message.
> 
> Please submit the agendas for your Working Group sessions using the "IETF
> Meeting Materials Management Tool," a Web-based tool for making your
> meeting agenda, minutes, and presentation slides available to the
> community before, during, and after an IETF meeting.  If you are a BOF
> chair, then you may use the tool to submit a revised agenda as well as
> other materials for your BOF once the BOF has been approved.
> 
> The URL for the tool is:
> 
> https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi
> 
> Additional information about this tool is available at:
> 
> http://www.ietf.org/instructions/meeting_materials_tool.html
> 
> Agendas submitted via the tool will be available to the public on the
> "IETF Meeting Materials" Web page as soon as they are submitted.
> 
> The URL for the "IETF 73 Meeting Materials" Web page is:
> 
> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=73
> 
> If you are a Working Group chair, then you already have accounts on the
> "IETF Meeting Session Request Tool" and the "IETF Meeting Materials
> Management Tool."  The same User ID and password will work for both tools.
>   If you are a BOF chair who is not also a Working Group chair, then you
> will be given an account on the "IETF Meeting Materials Management Tool"
> when your BOF has been approved.  If you require assistance in using
> either tool, or wish to report a bug, then please send a message to:
> ietf-action <at> ietf.org.
> ===============================================================
> For your convenience, comprehensive information on requesting meeting
> sessions at IETF 73 is presented below:
> 
> 1. Requests to schedule Working Group sessions should be submitted using
> the "IETF Meeting Session Request Tool," a Web-based tool for submitting
> all of the information required by the Secretariat to schedule your
> sessions.  The URL for the tool is:
> 
> https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi
> 
> Instructions for using the tool are available at:
> 
> http://www.ietf.org/instructions/session_request_tool_instruction.html
> 
> If you require an account on this tool, or assistance in using it, then
> please send a message to ietf-action <at> ietf.org.  If you are unable to use
> the tool, then you may send your request via e-mail to agenda <at> ietf.org,
> with a copy to the appropriate Area Director(s).
> 
> Requests to schedule BOF sessions must be sent to agenda <at> ietf.org with a
> copy to the appropriate Area Director(s).
> 
> When submitting a Working Group or BOF session request by e-mail, please
> include the Working Group or BOF acronym in the Subject line.
> 
> 2. BOFs will NOT be scheduled unless the Area Director(s) approved
> request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S)
> NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL
> DESCRIPTION, and the information requested in (4) below. (Please read the
> BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before
> requesting a session for a BOF.)
> 
> 3. A Working Group may request either one or two sessions.  If your
> Working Group requires more than two sessions, then your request must be
> approved by an Area Director.  Additional sessions will be assigned, based
> on availability, after Wednesday, October 22 at 17:00 PDT (24:00 UTC/GMT),
> the cut-off date for requests to reschedule a session.
> 
> 4. You MUST provide the following information before a Working Group or
> BOF session will be scheduled:
> 
>     a. Working Group or BOF full name with acronym in brackets: 
> 
>     b. AREA under which Working Group or BOF appears:
> 
>     c. CONFLICTS you wish to avoid, please be as specific as possible:
> 
>     d. Expected Attendance (figures from the 72nd IETF meeting are
> included at the end of this message):
> 
>     e. Special requests:
> 
>     f. Number of sessions:
> 
>     g. Length of session: 
>        - 1 hour 
>        - 1 1/2 hours
>        - 2 hours 
>        - 2 1/2 hours
> 
> For more information on scheduling Working Group and BOF sessions, please
> refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures"
> (http://www.ietf.org/rfc/rfc2418.txt).
> ===============================================================
> For your convenience please find here a list of the IETF Area Directors
> with their e-mail addresses:
> 
> IETF Chair 
> Russ Housley <housley <at> vigilsec.com>
> 
> Applications Area (app) 
> Lisa Dusseault <lisa <at> osafoundation.org>
> Chris Newman <chris.newman <at> sun.com>
> 
> Internet Area (int) 
> Jari Arkko <jari.arkko <at> piuha.net>
> Mark Townsley <townsley <at> cisco.com>
> 
> Operations & Management Area (ops) 
> Ronald Bonica <rbonica <at> juniper.net>
> Dan Romascanu <dromasca <at> avaya.com>
> 
> Real-time Applications and Infrastructure Area (rai)
> Cullen Jennings <fluffy <at> cisco.com>
> Jon Peterson <jon.peterson <at> neustar.biz>
> 
> Routing Area (rtg) 
> Ross Callon <rcallon <at> juniper.net>
> David Ward <dward <at> cisco.com>
> 
> Security Area (sec) 
> Pasi Eronen <pasi.eronen <at> nokia.com>
> Tim Polk <tim.polk <at> nist.gov>
> 
> Transport Area (tsv) 
> Lars Eggert <lars.eggert <at> nokia.com>
> Magnus Westerlund <magnus.westerlund <at> ericsson.com>
> ===========================================================
> 72nd IETF Meeting Attendance Number
> 
> 16ng 57
> 6lowpan 81
> 6man 90
> alto - BOF 243
> ancp 23
> apparea (AG) 53
> asrg (IRTF) 
> avt 75
> avt (2nd session) 20
> behave 108
> behave (2nd session) 41
> bliss 82
> bmwg 22
> capwap 
> ccamp 80
> ccamp (2nd session) 107
> csi 38
> dccp 38
> dhc 60
> dime 38
> dkim 62
> dna 26
> dnsext 72
> dnsop 111
> drinks 51
> eai 49
> ecrit 59
> emu 22
> enum 44
> explisp - BOF 105
> fecframe 14
> forces 29
> geopriv 75
> grow 87
> hip 34
> hiprg (IRTF) 73
> hokey 28
> httpbis 30
> idnabis 52
> idnabis (2nd session) 
> idr 108
> intarea (AG) 203
> ipdvb 10
> ipfix 
> ippm 32
> ippm++ - BOF 42
> ipr 19
> ipsecme 86
> isis 29
> isms 18
> keyprov 19
> kitten 11
> krb-wg 28
> l2vpn 135
> l3vpn 130
> lemonade 18
> manet 54
> mboned 56
> mediactrl 55
> mext 112
> mext (second session) 87
> mip4 35
> mipshop 63
> mmusic 65
> mobopts (IRTF) 50
> morg - BOF 24
> mpls 168
> mpls (2nd session) 159
> nea 37
> netconf 37
> netlmm 61
> netmod 37
> netmod (2nd session) 24
> nfsv4 12
> nsis 26
> ntp 22
> opsarea (AG) 57
> opsawg 36
> opsec 36
> p2psip 136
> pana 23
> pce 80
> pcn 47
> pim 44
> pkix 64
> pmol 26
> pwe3 129
> radext 29
> rtgarea (AG) 95
> rmt 16
> roll 104
> rrg (IRTF) 114
> rtgwg 102
> saag (AG) 75
> sasl 24
> savi 78
> sidr 45
> sieve 17
> simple 83
> sip 147
> sip (2nd session) 73
> sipping 155
> softwire 42
> speermint 112
> tana - BOF 178
> tcpm 23
> tictoc 68
> tls 44
> tsvarea (AG) 87
> tsvwg 73
> v6ops 177
> v6ops (2nd session) 70
> vcarddav 18
> xcon 51
> 
> 

OT: ISO 639-6 RA

Hi

It is with great regret that I write to inform you that ISO FDIS 639-6 may
never be published as standard.  After 7 years of hard work the standard is
about to fall through a lack of funding for the RA and the final development
stages of the standard.  BSI say that it does not now fit their current
business model.  I quote "Unfortunately, I am not able to confirm that BSI
will be able to assume any responsibility for the Registration Authority
(RA) associated with the standard. Our holdings of RAs and Maintenance
Agencies (MA) have been the subject of much internal discussion recently; we
have concluded they do not fit with our business model and are resource
heavy. Hence, over the past few months we have relinquished some of our
holdings, as we are unable to fund them."

As you all know, standards work is notoriously underfunded and unless BSI
can see a fat profit in it, it is a no go.  As you all also know, language
standards are supposed to be free!  A catch 22 situation!

If there is a UK based profit making organization out there that would like
to support this work please contact me. I would like to inform you that
standards development counts as R & D for the purposes of tax credits.  What
this effectively means is that a company that is currently in profit can
support ISO 639-6 and gain tax credits of 125%.  In other words, as far as I
am aware, it wouldn't cost anything and would save an additional 25% on your
tax bill.

I must now apologise to the members, Co-Chairs of LTRU and to ietf-languages
for posting this message but needs must.

Thanks for your time.

Best regards

Debbie Garside
Editor ISO FDIS 639-6

Debbie Garside
CEO

The World Language Documentation Centre
Corner House
Barn Street
Haverfordwest
Pembrokeshire SA61 1BW
Wales UK

Tel: 0044 1437 766441
Fax: 0044 1437 766173

Web: http://www.thewldc.org

Expanding the xx..yy ranges (was: Re: Two grandfathered tagsfor 'Hakka')

Re: Expanding the xx..yy ranges (was: Re: Two grandfatheredtagsfor 'Hakka')

Hi -

As a technical contributor:

> From: "Gerard Meijssen" <gerard.meijssen <at> gmail.com>
> To: <ltru <at> ietf.org>
> Sent: Monday, September 15, 2008 11:40 PM
> Subject: [Ltru] Expanding the xx..yy ranges (was: Re: Two grandfatheredtagsfor 'Hakka')
>
> Hoi,
> In Unix characters like slashes and pipes have a special purpose. When the
> name of a language is used as the title of a webpage, it often happens that
> as a consequence the page cannot be displayed. When the name of the article
> is another Unicode character, it does not have the same meaning and
> consequently the problem is just not there.
>
> It is by insisting on ASCII and the use of characters that are used for
> special purposes that this problem exists.

The only representations that the BCP offers for the use of protocols /
applications are those of the language tags themselves.  The format of
the registry is for the convenience of the registry maintenance process
and the developers of applications.

As a general principal of application design:  If an application imports
a field with a grammar which permits characters having special meaning
to that application, it's the application's responsibility to defend
against them.  Do you have a specific list of characters you'd like to
prohibit from use in description clauses, so a change to the grammar
could be proposed?

> The reason for using what is the code for a language is because the code is
> the only non changing unique part of the registration of a language. These
> codes are not only unique to this registry, they are also used in the
> ISO-639-3. When you make something unique in this way, you invite people to
> take these codes seriously.

But the 2- and 3- letter codes cannot contain any of the "offending" characters.
The characters that are potentially problematic if used carelessly (in shell
scripts, for example) show up in descriptions.  But description fields are not
"codes", they are *not* localized, nor are they exhaustive, nor are they even
guaranteed to be unique, even though we try to avoid ambiguity.  They're simply
there for reference and maintenance sanity.

Randy