Re: Excellent choice for summer meeting location!
Franck Martin wrote: On serious note: go in the Alps. The ski stations are nearly empty (no snow), they have huge capacity (some were Winter Olympic places), the weather is quite good and the scenery is breath taking. Might I suggest that you find a suitable venue and a sponsor that can provide connectivity to the venue and then suggest it. Having been through this process (and Jordi I started hassling for Adelaide at the Columbus meeting in 1993 and Jun spent a similar amount of time trying to get it to Tokyo so keep going :) I can say it's not easy trying to find a venue that can be configured for an IETF (multiple large meeting rooms) together with a large number of close by hotel rooms. Mark. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
Don't forget also: It is FULL of French! On serious note: go in the Alps. The ski stations are nearly empty (no snow), they have huge capacity (some were Winter Olympic places), the weather is quite good and the scenery is breath taking. Cheers Scott Bradner wrote: Glen rants: Are you then claiming that there is _nowhere_ in France that a) is capable of hosting a meeting with the IETF's requirements and b) the weather is more pleasant? =20 how about Paris? http://www.paris.org/Accueil/Climate/gifs/paris.climate.temp.html seems like the news story about extraordinary is also rare average max temp in Paris in july looks like 24 C and a bit lower in aug cooler than boston http://www.thisistravel.co.uk/travel/weather/location.html?in_location_id=205&in_page_id=1 average max temp in july 27 C now if you are coming from Seattle I can see that both might be considered deadly :-) see 4th paragraph of http://news.bbc.co.uk/1/hi/programmes/letter_from_america/3102625.stm Scott -- Franck Martin ICT Specialist franck@sopac.org SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
John: > How nice. In 2004, I discovered that I had no operational > experience and then that I knew nothing about standardization > processes outside the IETF. It is now only three days into 2005 > and already I've learned that I haven't been focused on "IT > globalization". I anxiously await the opportunity to find out > what comes next in this sequence :-) I did not mean to imply that you have no particular involvement in IT globalization, though I can see now that that is a likely way for my comment to have been read, and for that I apologize. For the past several years the majority of my work has been related to standards pertaining to IT globalization in one way or another, and I have encountered a few nexus of people interested in metadata elements for describing linguistic properties of content; a number of the people I have encountered in these contexts have congregated (metaphorically) on the IETF-languages list, and a number of those have provided input on this draft. In each of these contexts, I have encountered general agreement with the idea that it is appropriate to include writing-system distinction as part of language tags; after some time, it has only been in the past couple of weeks that I have encountered people who have questioned the decision to incorporate script IDs, and all of these have been people who have not been subscribed to the IETF-languages list, or at least have not been active contributors to discussion on that list. > It would be very helpful, to me at least, if you or he could > identify the specific context in which such tags would be used > and are required. The examples should ideally be of > IETF-standard software, not proprietary products. Chinese can be used as a good example for writing-system distinctions that cannot be captured in RFC 3066 using pre-defined values. A good example of an IETF protocol where such distinctions are needed is the accept-language field of HTTP page requests. For several years, Web site administrators encountered difficulties in providing appropriate choices to users using control mechanisms involving tags like zh-CN and zh-TW -- the tags simply did not correspond well with the localized content that they were needing to provide to users. Certainly outside of IETF protocols there are lots of scenarios not involving proprietary products in which RFC 3066 language tags are used and in which script distinctions like the Chinese example are a significant issue. This is a big issue for the localization industry, for example, and its various data-representation standards based on XML. More generally, there are a growing number of XML-based specifications for language resources and content, in many of which text is a major form of language data, and in all of these cases writing-system distinctions like those for Chinese are critically important. I've used Chinese as one example, but there are many other cases, some familiar to many and some less well known. Also, in relation to IETF protocols, I mentioned only HTTP, but the same problems likely exist for other protocol involving textual linguistic content where RFC 3066 is used. For example, in searching for items in an LDAP directory, in may be appropriate for an AttributeDescription to specify Tradition Chinese rather than Simplified Chinese, or Serbian using the Latin-script orthography vs. Serbian using the Cyrillic-based orthography. > I've just now skimmed parts of this paper. It is very > interesting and I look forward to carefully reading the rest of > it. We are in agreement about your category model. The only > place where there is a difference is whether, for the purposes > of the IETF and the actual demands on RFC 3066, something else > --and something as complex as I perceive this proposal as > being-- is really needed. In ideal terms, I do not think that all of the complexity of the proposed draft is needed. On the other hand, I think that some people's characterization of the excessive complexity has been overstated, some of the complexity I consider superfluous but not particularly harmful (notably the extensions), and some of the complexity I think is an unfortunate result of existing implementations and past practice (in particular, the steps taken to avoid instability of ISO 3166 and the use of both UN numeric IDs and ISO 3166 due to the combination of prior usage of ISO 3166-1 together with the need for region identifiers other than those provided by ISO 3166-1). > I can, for the record, believe that > this proposal is unnecessary and too complex Strictly speaking, any tag it proposes could be registered using the RFC 3066 registration process, so it could in some sense be claimed to be unnecessary. But there is no reason why not to allow generative combinations involving script IDs where such tags are needed since there's no need to state the semantics of the whole explicitly in such cases. And there *is* a need to avoid the problem you alluded to
RE: draft-phillips-langtags-08, process, specifications, and extensions
--On Monday, 03 January, 2005 17:49 -0800 Christian Huitema <[EMAIL PROTECTED]> wrote: > Could you please pursue this rather technical discussion on a > specialized list, rather than the main IETF list? Christian, It seems to me that we are in a bit of a procedural bind on this. The spec has been developed, we are told, on the "ietf-languages" list, but that is a mailing list, not a WG with a charter. The document is being processed as an individual submission, but an individual submission of a BCP that is intended to replace a BCP that arguably received broader community review and that is in fairly wide use. Whatever else the spec may be, it appears to be controversial, with at least some folks who are often considered (however wrongly) to have some idea about what they are talking about being quite dissatisfied with aspects of it. We are in (but nearing the end of) an IETF Last Call. It is unusual to Last Call an individual submission document that turns out to be this controversial, but the nature of the Last Call rules is such that the IETF list probably is the right place, at least procedurally, to have the discussion. >From my point of view, a note to the IESG asking that they formally abandon the Last Call given the level of controversy and find a WG (and WG mailing list) to assign the task of reaching some sort of agreement to would be entirely appropriate, but that is probably the only procedurally-correct way to get this off the IETF list while still leaving open the possibility of a document for which a claim of approval by IETF consensus could be made. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, specifications, and extensions
> "Christian" == Christian Huitema <[EMAIL PROTECTED]> writes: Christian> Could you please pursue this rather technical Christian> discussion on a specialized list, rather than the main Christian> IETF list? There is sort of this problem that most of this traffic is last call comments on a document. Our procedures require that last call comments be sent to ietf@ietf.org or [EMAIL PROTECTED] iesg@ietf.org is not a public list; so if you want to make a last call comment that is visible to the world, not just the IESG, you do need to copy [EMAIL PROTECTED] That said, I think this discussion could benefit from discussion on the ietf-languages lists with agreed summaries at the end of the last call period. Sam, speaking as an individual. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Language Tags: Response to a part of Jefsey's comments concerning the W3C
I'm not going to respond to most of Jefsey's comments. However, wearing my W3C hat for a moment Jefsey wrote: - "RFC 3066bis" wants to fix some of the W3C needs, in a way which would make these patches Internet standards. This is not the appropriate way. (There is a W3C document on its way, why two?) -- Let me be abundantly clear. "RFC 3066bis" (that is, draft-phillips-langtags) is not intended to solve or solely to solve needs described formally or informally by the W3C Internationalization WG nor, as far as I am aware, any other part of the W3C. Participants in the W3C I18N WG (such as, obviously, myself) and other W3C working groups have contributed to the development and review of the draft, but they have done so as individuals or as representatives of their organizations or employers. This document emphatically is not a product of the W3C, however. It is an individual submission to the IETF supported by many of the subscribers in the IETF-languages list (where it was developed) and by these various organizations. There is not yet a W3C document on its way related to language tags. In the draft charter renewing the Internationalization Working Group, which I hope is approved shortly, there is some discussion of guidelines for implementation of RFC 3066 and (I hope) its successor. There is also a specific work item to define locale identifiers for the World-Wide Web in general and Web services in particular. None of this work is in the current charter. It is my hope that this new charter will be approved to start soon. Locale identifiers are emphatically not the same thing as language tags. The use of RFC 3066 in W3C specifications has always been very clearly as language identifiers and never (to date) as a locale identifier. Although there is a relationship between the two applications and although RFC 3066 language tags have been used as a kind of de facto locale identifier in the past (especially by some Web applications with regard to the Accept-Language/Content-Language headers for HTTP), this should not suggest that some W3C specification is in the offing that overrides or supersedes RFC 3066 or its successor. Nor will the W3C I18N Core WG be chartered, AFAIK, to replace RFC 3066 (or its successor). To the extent that W3C specifications are important consumers of language tags, there is interest at W3C and I'm sure the W3C's official liasons will make the W3C's position (assuming that it has one) known at an appropriate time. Best Regards, Addison Addison P. Phillips Director, Globalization Architecture http://www.webMethods.com Chair, W3C Internationalization Working Group http://www.w3.org/International Internationalization is an architecture. It is not a feature. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, specifications, and extensions
Could you please pursue this rather technical discussion on a specialized list, rather than the main IETF list? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
Glen rants: > Are you then claiming that there is _nowhere_ in France that a) is > capable of hosting a meeting with the IETF's requirements and b) the > weather is more pleasant? =20 how about Paris? http://www.paris.org/Accueil/Climate/gifs/paris.climate.temp.html seems like the news story about extraordinary is also rare average max temp in Paris in july looks like 24 C and a bit lower in aug cooler than boston http://www.thisistravel.co.uk/travel/weather/location.html?in_location_id=205&in_page_id=1 average max temp in july 27 C now if you are coming from Seattle I can see that both might be considered deadly :-) see 4th paragraph of http://news.bbc.co.uk/1/hi/programmes/letter_from_america/3102625.stm Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
--On Monday, 03 January, 2005 12:29 -0800 Peter Constable <[EMAIL PROTECTED]> wrote: >> From: John C Klensin [mailto:[EMAIL PROTECTED] > >> Ignoring whether "that very nearly happened in RFC 3066", >> because some of us would have taken exception to inserting a >> script mechanism then, let's assume that 3066 can be >> characterized as a language-locale standard (with some funny >> exceptions and edge cases) and that the new proposal could >> similarly be characterized as a language-locale-script >> standard > > I can see we might run into some terminological hurdles here. > I would decidedly *not* describe RFC 3066 as a "locale" > standard just because it allows for tags that include country > identifiers. I would strongly contend that a "language" tag > and a "locale" ID are different things serving quite different > purposes. But I'll read the rest of your comments assuming > that by "language-locale(-script) standard" you simply mean a > standard for language tags that can include subtags for region > and script. That is more than close enough for discussion purposes. >> If one makes that assumption, then >> the (or a) framework for the answer to the question of what >> problem this solves that 3066 does not becomes clear: it meets >> the needs of when a language-locale-script specification is >> needed. >> >> But that takes us immediately to the comments Ned and I seem >> to be making, characterized especially by Ned's "sweet spot" >> remark. It has not been demonstrated that Internet >> interoperability generally, and the settings in which 3066 are >> now used in particular, require a language-local-script set of >> distinctions. > > I disagree. There are many cases in which script distinctions > in language tags have been recognized as being needed; several > such tags have been registered for that reason already under > the terms of RFC 3066, and there are more that would already > have been registered except for the fact that people have been > anticipating acceptance of this proposed revision. (For > instance, in response to recent discussions, a representative > of Reuters has indicated that he was holding off registering > various language tags that include ISO 15924 script IDs on > that basis, and that he plans to do so if this proposed > revision is delayed much longer.) It would be very helpful, to me at least, if you or he could identify the specific context in which such tags would be used and are required. The examples should ideally be of IETF-standard software, not proprietary products. >> The document does not address that issue. > > That is probably because those of us who have been > participants of the IETF-language list, where this draft > originated, have become so familiar with the need that it > seems obvious -- evidently, it's not as obvious to people that > have not been as focused on IT-globalization issues as we have. How nice. In 2004, I discovered that I had no operational experience and then that I knew nothing about standardization processes outside the IETF. It is now only three days into 2005 and already I've learned that I haven't been focused on "IT globalization". I anxiously await the opportunity to find out what comes next in this sequence :-) >> Equally important, but just as one example, in the MIME >> context (just one use of 3066, but a significant one), we've >> got a "charset" parameter as well as a "language" one. >> There are some odd new error cases if script is incorporated >> into "language" as an explicit component but is not supported >> in the relevant "charset". On the one hand, the document >> does not address those issues and that is, IMO, a problem. >> But, on the other, no matter how they are addressed, the >> level of complexity goes up significantly. > > I don't see how such error cases are significantly different > from current possibilities, such as having a language tag of > "hi" and a charset of ISO 8859-1 (where the content is > actually uses some non-standard encoding for Devanagari). Since I haven't paid attention to IT globalization and internationalization issues for the last 20 or 30 years, I obviously don't know enough about alphabetic equivalency relationships, the collection of TC 46 transliteration standards (including, in this case, the possibility that IS 15919 is in use), and related work to be able to address this question. >> One can also raise questions as to whether, if script >> specifications are really needed, those should reasonably be >> qualifiers or parameters associated with "charset" or >> "language" (and which one) rather than incorporated into the >> latter. I don't have any idea what the answer to those >> questions ought to be. > > Having worked on these particular issues for several years, I > and many others feel we *do* have an idea what the answer to > those questions ought to be -- that script should be > incorporated as a permitted subtag within a language tag. Good. See reque
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
On 20:37 03/01/2005, Peter Constable said: I note with interest that ccTLDs make use of ISO 3166 in spite of its potential for instability. In the case of ccTLDs, however, there is a considerable infrastructure for dealing with this: the DN system and strict procedures for deploying changes in ccTLDs onto domains. In the case of language tags, there are no such procedures for deploying changes in meanings of country identifiers across instances of metadata elements used to declare linguistic properties of information objects, nor is anything of that sort feasible in the general case. It may be that in the context of certain Internet protocols it is feasible to deploy changes in ISO 3166 across instances of language tags used by those protocols -- I don't know if this is true for any Internet protocols or not. It is certainly not true of all applications of ISO 639 standards that also make use of ISO 3166. Dear Peter, This is a very good documentation of the reason why the reference is not the ISO 3166, but the ccTLDs' reading (ie. RFC 1591). As the languages and users are not something which change in a possibly changing world, the ccTLD list is the best updated list to be used. Because it is directly in tune with the life of the world (in addition to be the one which references the IDNs, if they are ever used - which are necessary to call and use language web pages). Anyway any reference to IANA should recall that the IANA is now - like it or not - an ICANN function. I do not necessarily like an ICANN governance and prefer a global intergovernance, but I acknowledge that someone has to maintain the real life lists. Now, I am afraid you did not consider OPES (RFC 3914 - 3897 - 3838 - 3837 - 3836 - 3835 - 3752 and IAB RFC3238) and their capabilities as interstandard adapters. Please reread RFC 1958: only one principle will never change: that everything else will change. Let assume that I use my documented generalized language tag script-variation.language-dialect.country-area.type_of_application.authority, with different language matching algorithms, on an OPES server. I have no problem to serve all your W3C applications with all the RFC 3066nth like variation perfectly fitting tags (that is, if I know which "nth" brand you want), and MPEG, and etc. and may be to translate content accordingly (this is exactly the intent). jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
On 18:04 03/01/2005, John C Klensin said:
No, I really meant "pick one", since doing any combination I of
the three that I have been able to think about would just
produce more confusion.
John,
please review your propositions. They are not fully satisfactory because
each address (correctly) only one part of the problem. I suggest you reduce
the whole confusion to different identified sub-problems. Your solutions
are correct, for an RFC context.
What is needed here is, IMO, less confusion, not more.
Correct. This is why I suggest the above. The first confusion is about what
a language/country may be. The draft assumes that a language is an ISO
15924 code (and a country an ISO 3166 2 letter code). This fairy
"simplification" of the reality is the main source of confusion.
>> (i) Since we have no "Next-Best Current Practices"
>> category, publish this as an Informational Document,
>> moving it to BCP (and to "obsoletes 3066") only when
>> revisions of all documents that reference the 3066
>> registry (that includes not only IETF standards-track
>> and BCP documents, but also the ICANN IDN registration
>> procedures document and perhaps others) have been
>> written and have achieved community consensus.
>
> 100% in agreement.
To follow up slightly on Ned Freed's comments, I don't really
see any procedural way to do this, since it would require
synchronizing things that would likely defy synchronization.
That is especially true because we can't guarantee knowing about
all of them. But, since it is theoretically possible, I thought
it deserved mention. But one cannot both publish something as an
informational document and as a standards-track/BCP one, which
is what the second option calls for.
Full agreement. It is not feasible but it is mandatory: before being a BCP
it has to be a practice. This is why the draft can only be accepted as
informational in the RFC 3066 area, and to call for a effort towards an
interapplication consensus under IAB guidance: the "RFC 3066 ter" idea that
nobody opposes. This last document will target to be a standard and to
replace RFC 3066. The claim of the draft's author is not to publish a
standard, but an enhancement of RFC 3066. (They accepted the matching part
cannot belong to a standard).
>> (ii) Revise the introductory material in this document
>> to indicate that it is an alternative to 3066 that may
>> be more appropriate for some purposes and identify at
>> least some of those purposes. Revise the "registry
>> conversion" material to provide a way to seed the new
>> registry and, if appropriate, providing for
>> simultaneous registration in both registries for new
>> submissions. Based on those changes, indicate that it
>> modifies ("updates") 3066, rather than obsoleting it.
>> Most of my important concerns, although not some of
>> those that have been raised on the IETF list about
>> details, would disappear if this document paralleled,
>> rather than superceding, 3066.
>
> idem.
See above
idem. Indicating this is informational, and to work towards a further
consensual document, matches your propositions one and two.
I have no idea what you are talking about.
I am afraid this is the problem. We are not in your technical academic
field. We are in real usage, with commercial machines, supporting real life
exchanges with legal, cultural, etc. aspects. With real technologies,
buiness plan, billions of users and hundred of thousands of micro-cultures
etc. What you discuss leads to two disconnected geolinguistic grids. The
same as IDNAscii leads to nowhere, the same as IPv6 leads to NATs, this
will lead to confusion. Please let us stop being academic and let start
being realistic.
> ISO provides lists. Internet is about networking and needs
> internetworked lists. This internetworking calls for
> additional ad hoc descriptors.
Which is what 3066 does.
No. The two descriptors being used are the language code and the country
code. To some extend the scripting code is added. They are not able to
render all the dialects, regions and cities, areas, history, cultures, etc.
and all scripting, speaking variations and vernaculars the applications may
require - yet they assume they are. Most of all, networking them calls for
two key missing information in the tag: for which purpose and by which
authoritative who is this networking being made. This results into a lot of
subjective competent comments on the lists. I am sorry I do not ask my
telephone to be academic, I only ask it to work - in my daily world. And
this RFC 3066 stuff does not scale.
So the questions remain as to what
real problems we have in internetworking that 3066 does not
solve and, if there are such problems, whether they can be fixed
by a less radical and complex change to the 3066 framework.
There are two basic p
RE: Excellent choice for summer meeting location!
Couple of questions: -What kind of city with a population of 75,000 has hotel accommodations for 2000 people unless it's a tourist Mecca and likely expensive and overbooked? -What kind of mass transit does your typical city of that size have? On that note, what kind of car rental capacity is it going to have? Even though I'm from San Diego, certainly being able to go places on the subway/bus like we could in DC makes it a MUCH better location than a place like SD where it is VERY spread out, everyone has a car, and public transport is scarce relative to a lot of other places in the world. -If you can only just ADSL do you think a remote location will have the bandwidth to host 2000 IETFers sucking up bandwidth with their laptops and trying to broadcast meetings out to distant locations? -What kind of small city of such population has a large corporation willing to sponsor an IETF event? -How does making a big event take place in a small town help attendance? As for a couple of your propositions: -People usually get paid less outside of large cities because the cost of living is less so I don't see how that has any bearing, other than forcing everyone, including people living in other small towns to travel extra, and certainly guaranteeing that more people have to travel rather than less. -When you say "connections out in regional areas are often less than optimal for most people so this has an impact on online participation" I'm curious how putting a meeting outside a city would do ANYTHING for that situation, other than make travel more difficult and connectivity more limited. Certainly the people who live out of the range of high speed connectivity will not be helped by this maneuver. -You say "I'm sure there would be benefits in holding meetings at cities with populations ." but don't state any So, I'm not trying to be ruthless. Certainly moving out of a major metropolis does reduce many headaches/problems such as: -local costs: food/lodging etc. -less traffic and hassles associated with big cities But really these are convenience issues whereas the benefits of large venues address direct issues that relate to having a major conference: -lodging: big hotels with adequate facilities for such an event, as well as a reasonable number of more inexpensive lodgings for people on a budget -transport infrastructure: planes/trains/busses/subway/taxi -Entertainment: Yes people would like to have something to do in a place they go for a conference rather than being stuck with a hotel and a restaurant(reminds me of a couple trips to IBM in Burlington Vermont). Especially for those of us who pay for our trips to IETF meetings, they end up being pseudo-vacations to be able to justify. -Communications infrastructure: High bandwidth for IETF participants and multicast sessions. -Proximity: At our last meeting in DC there was an FTC summit on spam that many folks attended, and I personally attended a satellite meeting at UMD. Certainly being in a small town precludes the event from being near other large meetings, as well as organizations such as universities and larger corporations that provide local attendees, sponsorship, and other possibilities for people who are attending. Personally I'd LOVE to see more meetings in other parts of the world, as it adds a lot to a meeting, but I really don't see any far-reaching benefits to moving away from major city/metropolis areas, and can see a lot of reasons why it would be a problem. Just my thoughts... -Tom [EMAIL PROTECTED] > > Hello John > > I was being a little tongue in cheek but the suggestion of > regional centers being used is one I pursue for a lot of > groups. Living in the country in a smallish city, a lot of > meetings occur in the capitals that I and others just don't > get a chance to attend. I'm sure it would be the same in a > lot of areas. I can understand the issues but the benefits > all round may overcome them. For instance where I live is > only an hour flight from Sydney, you ask, why don't you fly > there for meetings and I have to explain, being in a regional > area, the finances available for travel are limited. We tend > to get paid less than equilivant workers in the capitals and > companies out here are less likely to approve spending on > non-essential travel. It is also a fact that connections out > in regional areas are often less than optimal for most people > so this has an impact for online participation. It is only > recently I was able to get ADSL at home for instance and > operated for years with a dialup that meant long hours for > participation online and I missed a lot of broadcasts due to > downloading constraints. > > My suggestion is the IETF considers moving some meetings out > to regional centres within reasonable travel of the major > ingress airports in an effort to promote awareness and > participation. Within the States and other countries, I'm > sure there would be some ben
RE: Excellent choice for summer meeting location!
Bill Strahm <> supposedly scribbled: > I don't know how airline pricing works in .au - but here in the .us > it seems that adding a short flight into a more regional airport can > more than double the cost of an airplane ticket. > > Also note that a town of 100,000 will seldom have conference space > that can host a conference that attracts 1500 people - I know of no > such facility in Hillsboro (where I live) that is outside of > Portland (more a suburb, than a regional center). I would be > interested in knowing what somewhere like Spokaine, Boise, or other > smaller site might have. I think that it might be possible in Spokane (grew up there but haven't been back in years). > > Bill > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Dassa > Sent: Monday, January 03, 2005 12:55 PM > To: 'John C Klensin'; 'IETF Discussion' > Subject: RE: Excellent choice for summer meeting location! > >>> -Original Message- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of John C Klensin Sent: Tuesday, January 04, 2005 12:19 AM >>> To: [EMAIL PROTECTED]; 'IETF Discussion' >>> Subject: RE: Excellent choice for summer meeting location! >>> Dassa, >>> >>> For better or worse, we've had a preference for locations close to >>> major airports with significant international connections. >>> We haven't been consistent about it (note, e.g., San Diego), but, >>> unlike that other organization whose name starts with "I" >>> (not IEEE, Glen), we have considered it a really bad thing if most >>> of the attendees have to spend two days getting to and/or from a >>> meeting: turning a five-day meeting into an >>> eight- or nine-day one is really hard on those who have other >>> things to do besides going to meetings.I have no idea how the >>> boondocks >>> of NSW would fall on that criterion, but it is what has kept us >>> near or in fairly major cities. >>> > > Hello John > > I was being a little tongue in cheek but the suggestion of regional > centers being used is one I pursue for a lot of groups. Living in > the country in a smallish city, a lot of meetings occur in the > capitals that I and others just don't get a chance to attend. I'm > sure it would be the same in a lot of areas. I can understand the > issues but the benefits all round may overcome them. For instance > where I live is only an hour flight from Sydney, you ask, why don't > you fly there for meetings and I have to explain, being in a regional > area, the finances available for travel are limited. We > tend to get paid less than equilivant workers in the capitals and > companies out here are less likely to approve spending on > non-essential travel. > It is > also a fact that connections out in regional areas are often less > than optimal for most people so this has an impact for online > participation. > It > is only recently I was able to get ADSL at home for instance and > operated for years with a dialup that meant long hours for > participation online and I missed a lot of broadcasts due to > downloading constraints. > > My suggestion is the IETF considers moving some meetings out to > regional centres within reasonable travel of the major ingress > airports in an effort to promote awareness and participation. Within > the States and other countries, I'm sure there would be some benefits > in holding meetings at cities with populations of 30,000 - 100,000 or > so rather than the capitals and other major cities with populations > into the millions. > > There are issues with such locations and they may be insurmountable > but I would like to see the idea considered. Given more people > making lifestyle changes that involve moving away from major cities, > it may become more important in the future. > > Darryl (Dassa) Lynch > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:Excellent choice for summer meeting location!
I don't care too much, if they use IPv6 ! but is also difficult to make them better than those that we had in Barcelona ;-) Regards, Jordi > De: Alexandru Petrescu <[EMAIL PROTECTED]> > Responder a: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Fecha: Mon, 03 Jan 2005 22:12:24 +0100 > Para: <[EMAIL PROTECTED]> > CC: > Asunto: Re: Excellent choice for summer meeting location! > > JORDI PALET MARTINEZ wrote: >> So what I can say is that I'm very happy that Paris is hosting this meeting >> and hope that some time Madrid has a similar opportunity, > > Oh, ok, yes, IETF, but where will the _Games_ be hosted? :-) > > Alex > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
I don't know how airline pricing works in .au - but here in the .us it seems that adding a short flight into a more regional airport can more than double the cost of an airplane ticket. Also note that a town of 100,000 will seldom have conference space that can host a conference that attracts 1500 people - I know of no such facility in Hillsboro (where I live) that is outside of Portland (more a suburb, than a regional center). I would be interested in knowing what somewhere like Spokaine, Boise, or other smaller site might have. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dassa Sent: Monday, January 03, 2005 12:55 PM To: 'John C Klensin'; 'IETF Discussion' Subject: RE: Excellent choice for summer meeting location! |> -Original Message- |> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] |> On Behalf Of John C Klensin |> Sent: Tuesday, January 04, 2005 12:19 AM |> To: [EMAIL PROTECTED]; 'IETF Discussion' |> Subject: RE: Excellent choice for summer meeting location! |> Dassa, |> |> For better or worse, we've had a preference for locations |> close to major airports with significant international connections. |> We haven't been consistent about it (note, e.g., San Diego), |> but, unlike that other organization whose name starts with "I" |> (not IEEE, Glen), we have considered it a really bad thing |> if most of the attendees have to spend two days getting to |> and/or from a meeting: turning a five-day meeting into an |> eight- or nine-day one is really hard on those who have |> other things to do |> besides going to meetings.I have no idea how the boondocks |> of NSW would fall on that criterion, but it is what has kept |> us near or in fairly major cities. |> Hello John I was being a little tongue in cheek but the suggestion of regional centers being used is one I pursue for a lot of groups. Living in the country in a smallish city, a lot of meetings occur in the capitals that I and others just don't get a chance to attend. I'm sure it would be the same in a lot of areas. I can understand the issues but the benefits all round may overcome them. For instance where I live is only an hour flight from Sydney, you ask, why don't you fly there for meetings and I have to explain, being in a regional area, the finances available for travel are limited. We tend to get paid less than equilivant workers in the capitals and companies out here are less likely to approve spending on non-essential travel. It is also a fact that connections out in regional areas are often less than optimal for most people so this has an impact for online participation. It is only recently I was able to get ADSL at home for instance and operated for years with a dialup that meant long hours for participation online and I missed a lot of broadcasts due to downloading constraints. My suggestion is the IETF considers moving some meetings out to regional centres within reasonable travel of the major ingress airports in an effort to promote awareness and participation. Within the States and other countries, I'm sure there would be some benefits in holding meetings at cities with populations of 30,000 - 100,000 or so rather than the capitals and other major cities with populations into the millions. There are issues with such locations and they may be insurmountable but I would like to see the idea considered. Given more people making lifestyle changes that involve moving away from major cities, it may become more important in the future. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
HIDEGA TIKU Lea RD-TCH-ISS wrote: France Telecom, the host for the 63rd IETF August 2005 meeting, is paying for the rental of the venue and provides the network. Please, where is the venue planned, if this information can be shared? Is it in the 75 or outside? Please don't take apparently harsh remarks as harsh, they often aren't. I for one and several people around me are very happy with the Paris setting - no travel. I was so jealous when it happened to London. Therefore, on behalf of France Telecom, I would like to insure the community that we are doing our best to make this meeting the most effective Thank you very much for that, I personally think it's a lot of effort. Any idea of the planned T-shirts, surprise? :-) Alex signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
JORDI PALET MARTINEZ <> supposedly scribbled: > Hi Hidega, > > I think you should not take so seriously this type of comments in the > IETF mail exploder. I think that that is excellent advice. > I could had a similar or even stronger reaction > ;-) > > I guess they come as a way to complain about the lack of transparency > in the way a venue is chosen, against the rules explained in the IETF > web page to host a meeting, the excessive number of meetings being > hold in US (were every time is worst and worst traveling to), etc., > etc.. Exactly. > > I've tried to get Madrid hosting it for more than 4 years, and we > still didn't succeed. I'm also working for a possible venue in Latin > America, hopefully will not take 4 years ;-), possibly in Mexico. Although it only took 9 months for me, I know something of what you are talking about. When I worked at Microsoft, I would often say to the CNRI folks something like "Why don't we meet in ___?" to which the answer was always "Get us a sponsor and we'll go." So I said, "We'll sponsor it!" and came up with a series of proposed venues in different countries, all of which met the CNRI criteria & all of which were rejected out of hand with various lame reasons. The word "boondoggle" was often used, since the proposed sites (which, by the way, included both Paris and Madrid at various points) were uniformly pleasant. They kept saying "Why not Seattle?" to which I responded "Because the weather in Seattle sucks" (note that I, personally, love Seattle -- in fact I moved here for the weather -- but I'm aware that most people are not as enamored of clouds & drizzle as I :-). The fact that we actually made it to Orlando is almost miraculous (note that we have never been back!). > > So what I can say is that I'm very happy that Paris is hosting this > meeting and hope that some time Madrid has a similar opportunity, > later we can think in Barcelona, Acapulco, and some other places > which definitively should not be in US. I wish you the best of luck! Cancun was on my list too, rejected as a "boondoggle". > > Regards, > Jordi > > > > >> De: HIDEGA TIKU Lea RD-TCH-ISS <[EMAIL PROTECTED]> >> Responder a: <[EMAIL PROTECTED]> >> Fecha: Mon, 3 Jan 2005 20:06:34 +0100 >> Para: <[EMAIL PROTECTED]>, >> CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, HIDEGA TIKU Lea >> RD-TCH-ISS <[EMAIL PROTECTED]> >> Asunto: RE: Excellent choice for summer meeting location! >> >> Dear Glen Zorn >> >> >> It is startling to see your remarks about, "Paris in August" as: >> >> a. "deadly". On your mail of 31/12/2004 >> >> b. "physical danger of meeting in Paris in August". On your mail of >> 31/12/2004 >> >> c. "the point is the question of why we seem to go out of our way to >> find unpleasant weather for our meetings". On your mail of >> 02/01/2005 >> >> So, what do you suggest?... >> >> To use the unfortunate weather calamity of August 2003 in France is a >> counterfeit reason to try and sabotage the work of many women and men >> working hard to make this meeting the most agreeable possible. This >> is equivalent to saying, not to go to New York because of 9/11 and >> not to ever go to Asia where the Tsunami had happened. >> >> I don't understand your motivation for acting this way; but, I would >> like to discuss this issue with Cisco officials. >> >> France Telecom, the host for the 63rd IETF August 2005 meeting, is >> paying for the rental of the venue and provides the network. >> Therefore, on behalf of France Telecom, I would like to insure the >> community that we are doing our best to make this meeting the most >> effective, efficient and safe (not >> "deadly") possible. We have reported the event to the security >> officials, and I will post the messages. >> >> Please let me know your remarks. >> >> Hidega >> >> -Message d'origine- >> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part >> de Glen Zorn (gwz) Envoyé : vendredi 31 décembre 2004 07:06 À : >> ietf@ietf.org Objet : Excellent choice for summer meeting location! >> >> Paris in August: >> http://www.usatoday.com/weather/news/2003-09-25-france-heat_x.htm >> >> ~gwz >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > > > ** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be > aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > > ___
RE: Excellent choice for summer meeting location!
HIDEGA TIKU Lea RD-TCH-ISS <> supposedly scribbled: > Dear Glen Zorn > > > It is startling to see your remarks about, "Paris in August" as: > > a."deadly". On your mail of 31/12/2004 > > b."physical danger of meeting in Paris in August". On your mail of > 31/12/2004 > > c."the point is the question of why we seem to go out of our way to > find unpleasant weather for our meetings". On your mail of > 02/01/2005 > > So, what do you suggest?... Are you then claiming that there is _nowhere_ in France that a) is capable of hosting a meeting with the IETF's requirements and b) the weather is more pleasant? > > To use the unfortunate weather calamity of August 2003 in France is a > counterfeit reason to try and sabotage the work of many women and men > working hard to make this meeting the most agreeable possible. Absolute nonsense! The meeting site and date is set, there is nothing to do about it now. BTW, when I saw in November that the _spring_ IETF was scheduled in Paris, I was absolutely overjoyed; in fact I thought that it had to be a mistake, that the powers-that-be would _never_ allow us to meet in one of (if not _the_) greatest cities in the world at the perfect time of the year. Unfortunately, my misgivings proved to be correct, for whatever reasons. > This > is equivalent to saying, not to go to New York because of 9/11 and > not to ever go to Asia where the Tsunami had happened. No, it's equivalent to saying not to go to Yokohama during typhoon season (which we already did) or Phoenix in August (I really should stop mentioning Arizona or we may end up there next summer ;-). > > I don't understand your motivation for acting this way; but, I would > like to discuss this issue with Cisco officials. Discuss away! As for my motivation, I attend these little geek-fests 3 times a year & have been doing so for longer than I care to admit. Since I am there for 6 days, I would really like to be able to go _outside_ and _enjoy_ it (or at least without risking either frostbite or heatstroke). Is that so hard to understand? (Before the flames start, yes, San Diego's weather is at least tolerable almost all the time -- I'm amazed we ever go there). > > France Telecom, the host for the 63rd IETF August 2005 meeting, is > paying for the rental of the venue and provides the network. That's unfortunate: when Microsoft hosted the IETF in Orlando the meeting rooms were free, contingent upon the level of guaranteed occupancy. > Therefore, on behalf of France Telecom, I would like to insure the > community that we are doing our best to make this meeting the most > effective, efficient and safe (not "deadly") possible. Did someone suggest that you weren't? > We have > reported the event to the security officials, and I will post the > messages. > > Please let me know your remarks. > > Hidega > > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part > de Glen Zorn (gwz) Envoyé : vendredi 31 décembre 2004 07:06 À : > ietf@ietf.org Objet : Excellent choice for summer meeting location! > > Paris in August: > http://www.usatoday.com/weather/news/2003-09-25-france-heat_x.htm > > ~gwz > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Language Tags to BCP: response to John Klensin
> Which is what 3066 does. So the questions remain as to what > real problems we have in internetworking that 3066 does not > solve and, if there are such problems, whether they can be fixed > by a less radical and complex change to the 3066 framework. There are real problems with the identification of languages outlined in a number of places in draft-langtags, the announcement, and elsewhere. These problems are not solved by RFC 3066 due to the design of the registration mechanism in particular. I'll come back to those in a separate message. First I want to address your rhetoric! :-) The description of draft-langtags as a "radical" and "complex" change to the RFC 3066 framework I think is unwarranted. Although there is a lot of additional content in the draft, most of this content focuses on establishing greater stability in the language tag framework, now and for the future. Your claim that the language tags defined by the draft are incompatible with RFC 3066 is false. Let me explain. First, all draft-langtags tags are *fully* backwards compatible with RFC 3066, both in terms of the ABNF and the possibility of those tags for registration. Every single such tag could be registered. Creating draft-langtags obviates the need to register every one of a potentially very large class of tags. Second, all RFC 3066 language tags are *fully* forward compatible with draft-langtags. The few tags that do not meet one or another requirement of the draft for subtag registration are grandfathered in. Third, registry conversion is a poor characterization of the process. RFC 3066's registry will continue to exist, but will no longer be maintained (it will be dead, since items cannot be added to it or, by RFC 3066's own rules, removed). draft-langtags will comprise a new registry that happens to contain everything previously defined by the RFC 3066 registry. Fourth and finally, references to RFC 3066 in extant RFCs and I-Ds need not be changed immediately. Certainly a transition period is warranted. In any case, implementations of RFC 3066 in Internet-Drafts and RFCs generally incorporate language tags or language ranges as holistic entities (as in: "this field identifies the language of the content using identifiers defined by RFC 3066") and do not refer to the specific content of the subtags. They may refer to the structure of a language tag, but as noted, the RFC 3066 syntax is compatible with that in draft-langtags. RFC 3066 processors (if they adhere to RFC 3066) will work correctly with draft-langtags tags. The handwringing about "breaking things" is incorrect, I believe. Yes, the document is different and the rules about what subtags can be registered are more strict, but these changes are internal to the framework of the registry and do not represent actual incompatibility as experienced by protocols, implementers, or end users. I should note: generally it is accepted practice to refer to "RFC 3066 or its successors" in many standards organizations (such as W3C) that reference language tags (since RFC 3066 itself obsoletes RFC 1766). Best Regards, Addison Addison P. Phillips Director, Globalization Architecture http://www.webMethods.com Chair, W3C Internationalization Working Group http://www.w3.org/International Internationalization is an architecture. It is not a feature. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
JORDI PALET MARTINEZ wrote: So what I can say is that I'm very happy that Paris is hosting this meeting and hope that some time Madrid has a similar opportunity, Oh, ok, yes, IETF, but where will the _Games_ be hosted? :-) Alex signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
|> -Original Message- |> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] |> On Behalf Of John C Klensin |> Sent: Tuesday, January 04, 2005 12:19 AM |> To: [EMAIL PROTECTED]; 'IETF Discussion' |> Subject: RE: Excellent choice for summer meeting location! |> Dassa, |> |> For better or worse, we've had a preference for locations |> close to major airports with significant international connections. |> We haven't been consistent about it (note, e.g., San Diego), |> but, unlike that other organization whose name starts with "I" |> (not IEEE, Glen), we have considered it a really bad thing |> if most of the attendees have to spend two days getting to |> and/or from a meeting: turning a five-day meeting into an |> eight- or nine-day one is really hard on those who have |> other things to do |> besides going to meetings.I have no idea how the boondocks |> of NSW would fall on that criterion, but it is what has kept |> us near or in fairly major cities. |> Hello John I was being a little tongue in cheek but the suggestion of regional centers being used is one I pursue for a lot of groups. Living in the country in a smallish city, a lot of meetings occur in the capitals that I and others just don't get a chance to attend. I'm sure it would be the same in a lot of areas. I can understand the issues but the benefits all round may overcome them. For instance where I live is only an hour flight from Sydney, you ask, why don't you fly there for meetings and I have to explain, being in a regional area, the finances available for travel are limited. We tend to get paid less than equilivant workers in the capitals and companies out here are less likely to approve spending on non-essential travel. It is also a fact that connections out in regional areas are often less than optimal for most people so this has an impact for online participation. It is only recently I was able to get ADSL at home for instance and operated for years with a dialup that meant long hours for participation online and I missed a lot of broadcasts due to downloading constraints. My suggestion is the IETF considers moving some meetings out to regional centres within reasonable travel of the major ingress airports in an effort to promote awareness and participation. Within the States and other countries, I'm sure there would be some benefits in holding meetings at cities with populations of 30,000 - 100,000 or so rather than the capitals and other major cities with populations into the millions. There are issues with such locations and they may be insurmountable but I would like to see the idea considered. Given more people making lifestyle changes that involve moving away from major cities, it may become more important in the future. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
> From: John C Klensin [mailto:[EMAIL PROTECTED] > Ignoring whether "that very nearly happened in RFC 3066", > because some of us would have taken exception to inserting a > script mechanism then, let's assume that 3066 can be > characterized as a language-locale standard (with some funny > exceptions and edge cases) and that the new proposal could > similarly be characterized as a language-locale-script standard I can see we might run into some terminological hurdles here. I would decidedly *not* describe RFC 3066 as a "locale" standard just because it allows for tags that include country identifiers. I would strongly contend that a "language" tag and a "locale" ID are different things serving quite different purposes. But I'll read the rest of your comments assuming that by "language-locale(-script) standard" you simply mean a standard for language tags that can include subtags for region and script. > If one makes that assumption, then > the (or a) framework for the answer to the question of what > problem this solves that 3066 does not becomes clear: it meets > the needs of when a language-locale-script specification is > needed. > > But that takes us immediately to the comments Ned and I seem to > be making, characterized especially by Ned's "sweet spot" > remark. It has not been demonstrated that Internet > interoperability generally, and the settings in which 3066 are > now used in particular, require a language-local-script set of > distinctions. I disagree. There are many cases in which script distinctions in language tags have been recognized as being needed; several such tags have been registered for that reason already under the terms of RFC 3066, and there are more that would already have been registered except for the fact that people have been anticipating acceptance of this proposed revision. (For instance, in response to recent discussions, a representative of Reuters has indicated that he was holding off registering various language tags that include ISO 15924 script IDs on that basis, and that he plans to do so if this proposed revision is delayed much longer.) > The document does not address that issue. That is probably because those of us who have been participants of the IETF-language list, where this draft originated, have become so familiar with the need that it seems obvious -- evidently, it's not as obvious to people that have not been as focused on IT-globalization issues as we have. > Equally important, but just as one example, in the MIME context > (just one use of 3066, but a significant one), we've got a > "charset" parameter as well as a "language" one. There are > some odd new error cases if script is incorporated into > "language" as an explicit component but is not supported in the > relevant "charset". On the one hand, the document does not > address those issues and that is, IMO, a problem. But, on the > other, no matter how they are addressed, the level of complexity > goes up significantly. I don't see how such error cases are significantly different from current possibilities, such as having a language tag of "hi" and a charset of ISO 8859-1 (where the content is actually uses some non-standard encoding for Devanagari). > One can also raise questions as to whether, if script > specifications are really needed, those should reasonably be > qualifiers or parameters associated with "charset" or "language" > (and which one) rather than incorporated into the latter. I > don't have any idea what the answer to those questions ought to > be. Having worked on these particular issues for several years, I and many others feel we *do* have an idea what the answer to those questions ought to be -- that script should be incorporated as a permitted subtag within a language tag. > But they are fairly subtle, the document doesn't address > them (at least as far as I can tell), and I see no way to get to > answers to them without a lot more specificity about what real > internetworking or interoperability problem you are trying to > solve. Some days ago, I made reference to a white paper I wrote a few years ago that explores the kinds of distinctions that need to be made in metadata elements declaring linguistic attributes of information objects. It's long, and there are some details I'd change, but that may provide a starting point. The people who have contributed to this draft are all familiar with these ideas. You can find this paper at http://www.sil.org/silewp/abstract.asp?ref=2002-003. Granted, this paper does not go into details regarding specific implementations. > Similarly, as we know, painfully, from other > internationalization efforts, the only comparisons that are easy > involve bit-string identity. Working out, at an application > level, when two "languages" under the 3066 system are close > enough that the differences can be ignored for practical > purposes is quite uncomfortable. Attempting similar logic for > this new proposal is mind-
Re: Excellent choice for summer meeting location!
Elwyn Davies wrote: Oh, and BTW I can go there on an (air-conditioned) train in only 3 hours. The USA should invest in a few high speed trains.. they are the world's best way to travel. There's a slightly bigger pond between the U.S. and France... Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:Excellent choice for summer meeting location!
Hi Hidega, I think you should not take so seriously this type of comments in the IETF mail exploder. I could had a similar or even stronger reaction ;-) I guess they come as a way to complain about the lack of transparency in the way a venue is chosen, against the rules explained in the IETF web page to host a meeting, the excessive number of meetings being hold in US (were every time is worst and worst traveling to), etc., etc.. I've tried to get Madrid hosting it for more than 4 years, and we still didn't succeed. I'm also working for a possible venue in Latin America, hopefully will not take 4 years ;-), possibly in Mexico. So what I can say is that I'm very happy that Paris is hosting this meeting and hope that some time Madrid has a similar opportunity, later we can think in Barcelona, Acapulco, and some other places which definitively should not be in US. Regards, Jordi > De: HIDEGA TIKU Lea RD-TCH-ISS <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Mon, 3 Jan 2005 20:06:34 +0100 > Para: <[EMAIL PROTECTED]>, > CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, HIDEGA TIKU Lea RD-TCH-ISS > <[EMAIL PROTECTED]> > Asunto: RE: Excellent choice for summer meeting location! > > Dear Glen Zorn > > > It is startling to see your remarks about, "Paris in August" as: > > a. "deadly". On your mail of 31/12/2004 > > b. "physical danger of meeting in Paris in August". On your mail of 31/12/2004 > > c. "the point is the question of why we seem to go out of our way to find > unpleasant weather for our meetings". On your mail of 02/01/2005 > > So, what do you suggest?... > > To use the unfortunate weather calamity of August 2003 in France is a > counterfeit reason to try and sabotage the work of many women and men working > hard to make this meeting the most agreeable possible. This is equivalent to > saying, not to go to New York because of 9/11 and not to ever go to Asia where > the Tsunami had happened. > > I don't understand your motivation for acting this way; but, I would like to > discuss this issue with Cisco officials. > > France Telecom, the host for the 63rd IETF August 2005 meeting, is paying for > the rental of the venue and provides the network. Therefore, on behalf of > France Telecom, I would like to insure the community that we are doing our > best to make this meeting the most effective, efficient and safe (not > "deadly") possible. We have reported the event to the security officials, and > I will post the messages. > > Please let me know your remarks. > > Hidega > > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Glen > Zorn (gwz) > Envoyé : vendredi 31 décembre 2004 07:06 > À : ietf@ietf.org > Objet : Excellent choice for summer meeting location! > > Paris in August: > http://www.usatoday.com/weather/news/2003-09-25-france-heat_x.htm > > ~gwz > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
> From: Peter Constable > I'd also like to observe that various members of TC 37 and the ISO 639- > RA/JAC have observed or participated in the development of this draft. For > my part, it is not the draft I would have developed if I had undertaken it, > but I see no problems with it from a TC 37 or ISO 639-RA/JAC perspective. I realized there are some additional comments I should make on the proposed revision of RFC 3066 from a TC 37 perspective. (Note: these comments are offered as an active participant in the work of TC 37 and as a member of the ISO 639-RA/JAC. They are not official statements of TC 37 or any of its sub-committees, but I believe they are a reasonable representation of prevailing opinion within TC 37.) One of the issues this draft attempts to deal with is potential instability of ISO identifiers and the damaging impact that can have on existing content and implementations. ISO 639-2:1998 specifies that its language identifiers may be changed given compelling reasons, but that an identifier may not be reassigned for a period of five years after such a change. ISO 639-1:2002 specifies that an identifier may not be reassigned for a period of *ten* years after such a change. In practice, there has been no case in which an ISO 639-1 or ISO 639-2 identifier was withdrawn and later reassigned. The ISO 639-RA/JAC and TC 37/SC 2 have increasingly taken up concerns for stability to the point that ISO DIS 639-3 has a very strict stability policy designed to ensure that declarations made on existing information objects do undergo any adverse changes. This includes a restriction that identifiers that are deprecated may never be reassigned with a different meaning. To the extent that this draft attempts to protect language tags from instability of ISO identifiers, TC 37 considers it very important to ensure that metadata elements declaring linguistic properties of information objects have stability in relation to their meaning, but feels that there is no significant risk of such instability coming from ISO 639. On the other hand, TC 37 has been very concerned about changes that have been made in ISO 3166 country identifiers in which identifiers that had prior meanings were reassinged with new meanings. ISO 3166 country identifiers have been used by applications of the ISO 639 family of standards to indicate sub-language distinctions, such as differences in spelling or lexical items. Such changes to country identifiers have potential for very detrimental effects on applications of the ISO 639 standards. I note with interest that ccTLDs make use of ISO 3166 in spite of its potential for instability. In the case of ccTLDs, however, there is a considerable infrastructure for dealing with this: the DN system and strict procedures for deploying changes in ccTLDs onto domains. In the case of language tags, there are no such procedures for deploying changes in meanings of country identifiers across instances of metadata elements used to declare linguistic properties of information objects, nor is anything of that sort feasible in the general case. It may be that in the context of certain Internet protocols it is feasible to deploy changes in ISO 3166 across instances of language tags used by those protocols -- I don't know if this is true for any Internet protocols or not. It is certainly not true of all applications of ISO 639 standards that also make use of ISO 3166. In the latter regard, I would like to point out that the IETF specification RFC 3066 is refereced for use in metadata in many other places than IETF protocols, one important application of this specification being its use for the xml:lang attribute in XML. To the extent that ISO 3166 country codes can be reassigned with new meanings, the potential for detrimental effects on RFC 3066 language tags at least in contexts such as XML is of concern to TC 37. To the extent that the proposed draft aims to protect language tags from instability of ISO 3166 country identifiers where there is potential for detrimental effects on metadata elements declaring linguistic properties of language resources and other information objects, TC 37 would view the intent to achieve stability a good thing. It may be that the way in which it aims to achieve this may not be the best in the IETF context -- that is for IETF and not TC 37 to say. In the long term, though, TC 37 would support measures that would lead to ensuring that language tags defined by RFC 3066 or its successors are not subject to detrimental changes in semantics. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
--On Monday, 03 January, 2005 09:58 -0800 Peter Constable <[EMAIL PROTECTED]> wrote: >> From: John C Klensin <[EMAIL PROTECTED]> > >> (iii) One way to read this document, and 3066 itself for >> that matter, is that they constitute a critique of IS >> 639 in terms of its adequacy for Internet use. > > Not exactly. It reflects that ISO 639 alone does not support > all of the linguistically-related distinctions that need to be > declared about content on the Internet -- something that ISO > 639 itself acknowledges (in general, not just in relation to > the Internet). >... > Thus, I would not describe this as a critique of ISO 639. It > is simply a recognition that ISO 639 itself makes that there > are language distinctions that often need to be made that ISO > 639 itself does not make. Peter, What I said was "critique of ISO 639 in terms of its adequacy for Internet use" and not "general critique of ISO 639". I think, despite differences in choice of language, your note says much the same thing. So, unless I profoundly misunderstand your note, we are in agreement on that subject. But let me, reluctantly, move on to substance at a slightly higher level of abstraction than has characterized most of the discussion so far. The reluctance is due to the statement that there was going to be another revision. We normally don't do that in the IETF: Last Calls are supposed to be about documents that are proposed for publication and, IMO, the IESG should have terminated the Last Call the moment the statement was made that a revision to address some of Bruce's comments was in progress. You observe that... > Just as RFC 1766/3066 also use ISO 3166 country codes to make > sub-language distinctions (e.g. to distinguish vocabulary or > spelling), so also there is a need to use ISO 15924 to > distinguish between different written forms of a given > language. The proposed draft incorporates ISO 15924 -- > something that very nearly happened in RFC 3066, but did not > since ISO 15924 was still in process and (as I see it) those > of us involved needed more time to evaluate the idea (which has > happened in the years since then, to the point that we have > confindence about this step). Ignoring whether "that very nearly happened in RFC 3066", because some of us would have taken exception to inserting a script mechanism then, let's assume that 3066 can be characterized as a language-locale standard (with some funny exceptions and edge cases) and that the new proposal could similarly be characterized as a language-locale-script standard (and let's mostly ignore the question of whether there are funny exceptions and edge cases). If one makes that assumption, then the (or a) framework for the answer to the question of what problem this solves that 3066 does not becomes clear: it meets the needs of when a language-locale-script specification is needed. But that takes us immediately to the comments Ned and I seem to be making, characterized especially by Ned's "sweet spot" remark. It has not been demonstrated that Internet interoperability generally, and the settings in which 3066 are now used in particular, require a language-local-script set of distinctions. The document does not address that issue. Equally important, but just as one example, in the MIME context (just one use of 3066, but a significant one), we've got a "charset" parameter as well as a "language" one. There are some odd new error cases if script is incorporated into "language" as an explicit component but is not supported in the relevant "charset". On the one hand, the document does not address those issues and that is, IMO, a problem. But, on the other, no matter how they are addressed, the level of complexity goes up significantly. One can also raise questions as to whether, if script specifications are really needed, those should reasonably be qualifiers or parameters associated with "charset" or "language" (and which one) rather than incorporated into the latter. I don't have any idea what the answer to those questions ought to be. But they are fairly subtle, the document doesn't address them (at least as far as I can tell), and I see no way to get to answers to them without a lot more specificity about what real internetworking or interoperability problem you are trying to solve. Similarly, as we know, painfully, from other internationalization efforts, the only comparisons that are easy involve bit-string identity. Working out, at an application level, when two "languages" under the 3066 system are close enough that the differences can be ignored for practical purposes is quite uncomfortable. Attempting similar logic for this new proposal is mind-boggling, especially if one begins to contemplate comparison of a language-locale specification with a language-script one -- a situation that I believe from reading the spec is easily possible. That situation almost invites profiling of how this specification should
RE: Excellent choice for summer meeting location!
Dear Glen Zorn It is startling to see your remarks about, "Paris in August" as: a. "deadly". On your mail of 31/12/2004 b. "physical danger of meeting in Paris in August". On your mail of 31/12/2004 c. "the point is the question of why we seem to go out of our way to find unpleasant weather for our meetings". On your mail of 02/01/2005 So, what do you suggest?... To use the unfortunate weather calamity of August 2003 in France is a counterfeit reason to try and sabotage the work of many women and men working hard to make this meeting the most agreeable possible. This is equivalent to saying, not to go to New York because of 9/11 and not to ever go to Asia where the Tsunami had happened. I don't understand your motivation for acting this way; but, I would like to discuss this issue with Cisco officials. France Telecom, the host for the 63rd IETF August 2005 meeting, is paying for the rental of the venue and provides the network. Therefore, on behalf of France Telecom, I would like to insure the community that we are doing our best to make this meeting the most effective, efficient and safe (not "deadly") possible. We have reported the event to the security officials, and I will post the messages. Please let me know your remarks. Hidega -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Glen Zorn (gwz) Envoyé : vendredi 31 décembre 2004 07:06 À : ietf@ietf.org Objet : Excellent choice for summer meeting location! Paris in August: http://www.usatoday.com/weather/news/2003-09-25-france-heat_x.htm ~gwz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
> "Wijnen," == Wijnen, Bert (Bert) <[EMAIL PROTECTED]> writes: Wijnen,> The current text in section 3, 1st para states Wijnen,> The IAOC consists of volunteers, Wijnen,> does that not say enough? I think it does. I haven't seen an argument for why more text is needed in the BCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, specifications, "stability", and extensions
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of Bruce Lilly > > I don't think it's that uncommon to refer to a specification A that > makes use of another specification B as an application of B. > > Perhaps, but I think it's best to avoid misunderstanding in > technical discussion by being precise in use of terminology. I was being precise. Note that ISO 639 uses "application of language identifiers" in exactly the same sense in which I have used "application of RFC 3066". Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
The *meaning* of any given language tag would be no more or less a
problem under the proposed revision than it was for RFC 3066 or RFC
1766. For instance, there is a concurrent thread that has been
discussing when country distinctions are appropriate or recommended
("ca" or "ca-ES"?); this discussion pertains to RFC 3066, and part
of the issue is that meanings of tags are implied rather than
specified -- and always have been even under RFC 1766 (I pointed
this out five years ago when we were working on preparing RFC 3066).
So, for instance, when an author uses "de-CH", what does he intend
recipients to understand to be the difference between that and
"de-DE" or even "de"? Neither RFC 1766 or RFC 3066 shed any light on
this, and ultimately only the author knows for sure.
Under RFC 3066, it was the *exceptional* case that a complete tags
was registered, allowing some indication of the meaning of the whole
(though even in that regard nothing really required that the
documentation provide clear indication of the meaning). The 98%
cases were those like "de-CH" in which it was assumed that everyone
would understand what the intended meaning is.
This whole question of what 'matches' is subtle. Consider the case
when I have a document that has variant content by language (e.g.
different sound tracks), and the user indicates a set of preferred
languages. If the content has "de-CH" and "fr-CH" (swiss german and
french), and a default "en" (english) and the user says he speaks
"de-DE" and "fr-FR", on the face of it nothing matches, and I fall
back to the catch-all default, which is almost certainly not the best
result.
--
David Singer
Apple Computer/QuickTime
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call on Language Tags (RE: draft-phillips-langtags-08)
> From: John C Klensin <[EMAIL PROTECTED]> > (iii) One way to read this document, and 3066 itself for > that matter, is that they constitute a critique of IS > 639 in terms of its adequacy for Internet use. Not exactly. It reflects that ISO 639 alone does not support all of the linguistically-related distinctions that need to be declared about content on the Internet -- something that ISO 639 itself acknowledges (in general, not just in relation to the Internet). Just as RFC 1766/3066 also use ISO 3166 country codes to make sub-language distinctions (e.g. to distinguish vocabulary or spelling), so also there is a need to use ISO 15924 to distinguish between different written forms of a given language. The proposed draft incorporates ISO 15924 -- something that very nearly happened in RFC 3066, but did not since ISO 15924 was still in process and (as I see it) those of us involved needed more time to evaluate the idea (which has happened in the years since then, to the point that we have confindence about this step). RFC 1766/3066 also allowed tags to include subtags used for various purposes, and some tags have been registered to reflect sub-language variations other than those that can be captured using country (or script) IDs. This is another way in which ISO 639 alone is not sufficient, and the need for tags that include such variant subtags has been demonstrated. The proposed draft constrains the structure of tags including such variant subtags so as to avoid haphazard and inconsistent structuring of tags, which would present signficant problems. (Of course, that is not all that the proposed draft does.) Thus, I would not describe this as a critique of ISO 639. It is simply a recognition that ISO 639 itself makes that there are language distinctions that often need to be made that ISO 639 itself does not make. > From > that perspective, the difference between the two is that > 3066 was prepared specifically to meet known and > identifiable Internet protocol requirements that were > not in the scope of IS 639. The new proposal is more > general and seems to have much the same scope as ISO > 639-2 has, or should have. The scope of what is needed for Internet language tags is greater than the scope of ISO 639-2, which is even more limited than the general comments I made about wrt ISO 639 (which comments are equally applicable to ISO 639-1, ISO 639-2 or ISO DIS 639-3). > It is not in the IETF's > interest to second-guess the established standards of > other standards bodies when that can be avoided and, > despite the good efforts of an excellent and qualified > choice or tag reviewer, this is not an area in which the > IETF (and still less the IANA) are deeply expert. So > there is a case to be made that this draft should be > handed off to ISO TC 37 for processing, either for > integration into IS 639-2 or, perhaps, as the basis of a > new document that integrates the language coding of > 639-2 with the script coding of IS 15924. Speaking as a member of TC 37, of the ISO 639-RA Joint Advisory Committee, and project editor for ISO 639-3, I can say that it would be possible for TC 37 to take on a project to develop a standard for language-tags that addresses some of the needs this draft is attempting to meet, such as integrating ISO 15924. Note, though, that incorporation of this draft (or even RFC 1766/3066) into ISO 639-2 would be well beyond the scope of ISO 639-2. Something of this nature would necessarily involve a distinct standard, and perhaps one that is not part of the ISO 639 series. I'd also like to observe that various members of TC 37 and the ISO 639-RA/JAC have observed or participated in the development of this draft. For my part, it is not the draft I would have developed if I had undertaken it, but I see no problems with it from a TC 37 or ISO 639-RA/JAC perspective. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
--On Monday, 03 January, 2005 16:43 +0100 "JFC (Jefsey) Morfin"
<[EMAIL PROTECTED]> wrote:
> At 13:56 03/01/2005, John C Klensin wrote:
>> I hope these are mutually exclusive.
>
> Yes, if this means that the three of them should be aggregated
> into the final strategy.
No, I really meant "pick one", since doing any combination I of
the three that I have been able to think about would just
produce more confusion. What is needed here is, IMO, less
confusion, not more.
>> (i) Since we have no "Next-Best Current Practices"
>> category, publish this as an Informational Document,
>> moving it to BCP (and to "obsoletes 3066") only when
>> revisions of all documents that reference the 3066
>> registry (that includes not only IETF standards-track
>> and BCP documents, but also the ICANN IDN registration
>> procedures document and perhaps others) have been
>> written and have achieved community consensus.
>
> 100% in agreement.
To follow up slightly on Ned Freed's comments, I don't really
see any procedural way to do this, since it would require
synchronizing things that would likely defy synchronization.
That is especially true because we can't guarantee knowing about
all of them. But, since it is theoretically possible, I thought
it deserved mention. But one cannot both publish something as an
informational document and as a standards-track/BCP one, which
is what the second option calls for.
>> (ii) Revise the introductory material in this document
>> to indicate that it is an alternative to 3066 that may
>> be more appropriate for some purposes and identify at
>> least some of those purposes. Revise the "registry
>> conversion" material to provide a way to seed the new
>> registry and, if appropriate, providing for
>> simultaneous registration in both registries for new
>> submissions. Based on those changes, indicate that it
>> modifies ("updates") 3066, rather than obsoleting it.
>> Most of my important concerns, although not some of
>> those that have been raised on the IETF list about
>> details, would disappear if this document paralleled,
>> rather than superceding, 3066.
>
> idem.
See above
>> (iii) One way to read this document, and 3066 itself
>> for that matter, is that they constitute a critique
>> of IS 639 in terms of its adequacy for Internet use.
>> From that perspective, the difference between the two
>> is that 3066 was prepared specifically to meet known
>> and identifiable Internet protocol requirements that
>> were not in the scope of IS 639. The new proposal is
>> more general and seems to have much the same scope as
>> ISO 639-2 has, or should have. It is not in the
>> IETF's interest to second-guess the established
>> standards of other standards bodies when that can be
>> avoided and, despite the good efforts of an excellent
>> and qualified choice or tag reviewer, this is not an
>> area in which the IETF (and still less the IANA) are
>> deeply expert. So there is a case to be made that
>> this draft should be handed off to ISO TC 37 for
>> processing, either for integration into IS 639-2 or,
>> perhaps, as the basis of a new document that
>> integrates the language coding of 639-2 with the
>> script coding of IS 15924.
And, while possibilities I haven't foreseen are certainly
possible, it is generally the case that one cannot throw
something over a wall and hold onto it as well.
> Full agreement to refer to stabilized ISO 639-2 and 15924 (and
> to a more geographically/politically precise list that 3166
> only), but through documents adapting them to the Internet
> multiple orthogonal and/or related demands and permitting to
> generalize them to the Internet usage for global application
> consistency.
>
> Otherwise we would have two (or more) geopoliticalinguistic
> grids in use. IMHO the correct solution are dedicated RFCs
> (compatible with RFC 1591 for country codes) encapsulating ISO
> 639-3 and 15924 into a more global information container
> including application destination and sources descriptors.
I have no idea what you are talking about. If you have a
specific proposal, might I suggest that you generate an
Internet-Draft and indicate whether it should be taken as an
alternative or supplemental to the draft-phillips-langtag
document? If you do so, _please_ precisely identify what
problem of the actual Internet --rather than some fantasy
replacement-- you are proposing to solve.
> ISO provides lists. Internet is about networking and needs
> internetworked lists. This internetworking calls for
> additional ad hoc descriptors.
Which is what 3066 does. So the questions remain as to what
real problems we have in internetworking that
Re: Excellent choice for summer meeting location!
[EMAIL PROTECTED] wrote: Uh - how is Paris going to be physically dangerous. Are there terrorists planning on blowing up a tower, I really don't think a few warm days count as physically dangerous to most of the crowd I see at IETF meetings... This morning on radio - announce a trial of a very specific group with a very specific plan of a very specific threat of a consular setting here in Paris... Alex ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
> I have been following the extensive discussions of this subject > on the IETF and Language-Tags lists (somewhat over 100 relevant > messages by my rough count, although with the vast major of them > from around five participants). I note that much of it has not > been explicitly copied to the IESG list. For a number of > reasons, I've deliberately avoided making public comments to > date, but want to summarize some reactions before the Last Call > closes. I believe I did comment on this once on the languages list, but otherwise I'm in pretty much the same position as John on this. > (1) I had two key concerns when Harald asked me to look at an > early version of this draft. They continued with the first last > call version, and a still concerns with this version. They > were and are: > (i) It is significantly more complicated than RFC 3066, > which it proposes to replace. While this is clearly an > interesting intellectual exercise, that additional > complexity is not clearly justified. I.e., if we are > going to replace a standard that is in > (apparently-successful) use with one that is more > complex, the added complexity should be strongly > justified in terms of requirements and problems being > solved.While section 6 of the current draft provides > some of the relevant motivation, it is not nearly strong > enough, IMO, to justify the replacement. John, I could not agree more. It seems to me that the significant increase in complexity called for by this document is at best an attempt to address issues faced by at best a tiny fraction of the community that uses language tags. The vast majority of uses don't require any of this. And I suspect the overwhelming response to this proposal is going to be to simply ignore it. And this, in turn, is likely to create an unfortunate situation where the majority of use is aligned with obsoleted documents and the current documents describe usage that's restricted to largely academic venues. More generally, there's often a big difference between designing a good operational standard for the Internet and designing a good scheme for academic use. All too often a successful standard depends on identifying and specifying a "sweet spot", whereas academic use depends on total inclusiveness. I believe 3066 came pretty close to hitting a sweet spot for language tags, whereas this revision favors inclusiveness over usability. > (ii) The notion of "converting" an IANA registry (see > Appendix C) has little precedent in the IETF or in IANA > and I would suggest that we do not have a good track > record for such conversions. The authors propose to > maintain the existing registrations in the existing > registry but not add new ones there. The resultant > status of standards-track documents that reference 3066 > and its registry is unclear. Presumably, those > documents would need to be revised and re-processed to > update them to reference the new spec and registry and > implementations that are non-conformant to the new rules > would need to be changed. From an IETF procedural > standpoint, that would require replacing at least some > documents that are now at Draft Standard with new > Proposed Standards, which has been a major source of > user and implementer confusion. It is something we have > done when we have to, but the justification does not > appear to be present in this document This is all just more impetus to keep on using the old stuff and ignore the current effort entirely. > ... > (2) Some days ago, the authors indicated that they were > producing and posting a new version of the draft in response to > some of the on-list comments. Some of those comments were > quite substantive, others probably not. That new draft has not > yet appeared; I suggest that, if any of the changes might be > substantive, it will require a new round of community review to > determine whether any changes that have been made have a > negative impact on requirements or other details that were > previously acceptable and to identify any comments that were > withheld pending the new draft. This is particularly important > since the document proposes to supercede and replace an existing > BCP and IANA registry that are in active use. I.e., this is > going to need yet another Last Call. I reluctantly have to agree with this assessment. > (3) Rather than moving to an almost-unprecedented third Last > Call (with more to come if this process is to continue as it has > proceeded in the past), I'd like to offer three alternate > suggestions. I hope these are mutually exclusive. > (i) Since we have no "Next-Best Current Practices" > category, publish this as an Informational Document, > moving it to BCP (and to "obsoletes 3066") only when > revisio
Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
At 13:56 03/01/2005, John C Klensin wrote:
I hope these are mutually exclusive.
Yes, if this means that the three of them should be aggregated into the
final strategy.
(i) Since we have no "Next-Best Current Practices"
category, publish this as an Informational Document,
moving it to BCP (and to "obsoletes 3066") only when
revisions of all documents that reference the 3066
registry (that includes not only IETF standards-track
and BCP documents, but also the ICANN IDN registration
procedures document and perhaps others) have been
written and have achieved community consensus.
100% in agreement.
(ii) Revise the introductory material in this document
to indicate that it is an alternative to 3066 that may
be more appropriate for some purposes and identify at
least some of those purposes. Revise the "registry
conversion" material to provide a way to seed the new
registry and, if appropriate, providing for simultaneous
registration in both registries for new submissions.
Based on those changes, indicate that it modifies
("updates") 3066, rather than obsoleting it. Most of
my important concerns, although not some of those that
have been raised on the IETF list about details, would
disappear if this document paralleled, rather than
superceding, 3066.
idem.
(iii) One way to read this document, and 3066 itself for
that matter, is that they constitute a critique of IS
639 in terms of its adequacy for Internet use. From
that perspective, the difference between the two is that
3066 was prepared specifically to meet known and
identifiable Internet protocol requirements that were
not in the scope of IS 639. The new proposal is more
general and seems to have much the same scope as ISO
639-2 has, or should have. It is not in the IETF's
interest to second-guess the established standards of
other standards bodies when that can be avoided and,
despite the good efforts of an excellent and qualified
choice or tag reviewer, this is not an area in which the
IETF (and still less the IANA) are deeply expert. So
there is a case to be made that this draft should be
handed off to ISO TC 37 for processing, either for
integration into IS 639-2 or, perhaps, as the basis of a
new document that integrates the language coding of
639-2 with the script coding of IS 15924.
Full agreement to refer to stabilized ISO 639-2 and 15924 (and to a more
geographically/politically precise list that 3166 only), but through
documents adapting them to the Internet multiple orthogonal and/or related
demands and permitting to generalize them to the Internet usage for global
application consistency.
Otherwise we would have two (or more) geopoliticalinguistic grids in use.
IMHO the correct solution are dedicated RFCs (compatible with RFC 1591 for
country codes) encapsulating ISO 639-3 and 15924 into a more global
information container including application destination and sources
descriptors.
ISO provides lists. Internet is about networking and needs internetworked
lists. This internetworking calls for additional ad hoc descriptors.
Thank you.
jfc
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
"Soininen Jonne (Nokia-NET/Helsinki)" <[EMAIL PROTECTED]> writes: > Bert, > > On Mon, 2005-01-03 at 16:46, ext Wijnen, Bert (Bert) wrote: >> Scott reponds to Jonne: >> > >> > Jonne asks: >> > > would >> > > x.x Compensation for IOAC members >> > > The IOAC members shall not receive any compensation (apart from >> > > reimbursement of expenses) for their services as members of the >> > > IOAC." >> > > >> > > do the trick then? >> > >> > works for me >> > >> personal opinion: >> Not for me. It seems to make it autotmatic that IAOC members DO receive >> reimbursement for expenses. I think I can live with the fact that thye >> may get it in special circumstances, but I do not like the idea >> that text suggests that it is normal to reimburse them. >> >> The current text in section 3, 1st para states >> >> The IAOC consists of volunteers, >> >> does that not say enough? > > I don't think that is quite enough, IMHO. I think the fact that the IAOC > members are not to be payed for their services (no compensation for lost > free time) should be documented. I am (as my original proposal was not > to have the IAOC people reimbursed at all) sympathetic of the idea to > optimise the IASA funds by having reimbursements being rather an > exception than a rule. I just thought that many people were saying that > they for some reason would like the IAOC being treated a bit better than > the IESG/IAB... I don't think that anyone is saying that. However, AFAIK there's in fact no rule prohibiting IESG/IAB members from being directly paid by IETF--not that that's a likely event. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
On Mon, 2005-01-03 at 17:10, ext Brian E Carpenter wrote: > Scott Bradner wrote: > > bert asks: > > > >>The current text in section 3, 1st para states > >> The IAOC consists of volunteers, > >>does that not say enough? > > > > > > I'd say no - volunteers can get paid in some cases > > x.x Compensation for IOAC members > > > The IOAC members shall not receive any compensation (apart from > > > exceptional reimbursement of expenses) for their services as > > > members of the IOAC." > > Does this fix Bert's objection? Works at least for me. > > Brian > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
Bert, On Mon, 2005-01-03 at 16:46, ext Wijnen, Bert (Bert) wrote: > Scott reponds to Jonne: > > > > Jonne asks: > > > would > > > x.x Compensation for IOAC members > > > The IOAC members shall not receive any compensation (apart from > > > reimbursement of expenses) for their services as members of the > > > IOAC." > > > > > > do the trick then? > > > > works for me > > > personal opinion: > Not for me. It seems to make it autotmatic that IAOC members DO receive > reimbursement for expenses. I think I can live with the fact that thye > may get it in special circumstances, but I do not like the idea > that text suggests that it is normal to reimburse them. > > The current text in section 3, 1st para states > > The IAOC consists of volunteers, > > does that not say enough? I don't think that is quite enough, IMHO. I think the fact that the IAOC members are not to be payed for their services (no compensation for lost free time) should be documented. I am (as my original proposal was not to have the IAOC people reimbursed at all) sympathetic of the idea to optimise the IASA funds by having reimbursements being rather an exception than a rule. I just thought that many people were saying that they for some reason would like the IAOC being treated a bit better than the IESG/IAB... Cheers, Jonne. > > Bert > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Scott Bradner wrote:
bert asks:
The current text in section 3, 1st para states
The IAOC consists of volunteers,
does that not say enough?
I'd say no - volunteers can get paid in some cases
x.x Compensation for IOAC members
> > The IOAC members shall not receive any compensation (apart from
> > exceptional reimbursement of expenses) for their services as
> > members of the IOAC."
Does this fix Bert's objection?
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
I agree with Bert. The current text says enough.
Margaret
At 3:46 PM +0100 1/3/05, Wijnen, Bert (Bert) wrote:
Scott reponds to Jonne:
Jonne asks:
> would
> x.x Compensation for IOAC members
> The IOAC members shall not receive any compensation (apart from
> reimbursement of expenses) for their services as members of the
> IOAC."
>
> do the trick then?
works for me
personal opinion:
Not for me. It seems to make it autotmatic that IAOC members DO receive
reimbursement for expenses. I think I can live with the fact that thye
may get it in special circumstances, but I do not like the idea
that text suggests that it is normal to reimburse them.
The current text in section 3, 1st para states
The IAOC consists of volunteers,
does that not say enough?
Bert
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
> bert asks: > > The current text in section 3, 1st para states > > The IAOC consists of volunteers, > > does that not say enough? > > I'd say no - volunteers can get paid in some cases > Sure... sometimes they also get a bottle of wine with Xmas. Should we add clear text about that too? Bert :-)/2 > Scott > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Issue #727: Section 2.2, 4, & 7 - Miscellaneous & editorial
Inline > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > John C Klensin > Sent: Sunday, January 02, 2005 18:41 > To: Scott Bradner; ietf@ietf.org > Subject: Re: Issue #727: Section 2.2, 4, & 7 - Miscellaneous & editorial > > --On Sunday, 02 January, 2005 08:19 -0500 Scott Bradner > <[EMAIL PROTECTED]> wrote: > > > > brian asks > >> Perhaps we do indeed need to explicitly limit the > >> IAOC Chair to chairing the IAOC. But we almost do - the > >> following paragraph says: > >> > >> The chair of the IAOC shall have the authority to manage > >> the activities and meetings of the IAOC. The IAOC Chair > >> has no formal duty to represent the IAOC, except as > >> directed by IAOC consensus. > >> > >> Isn't this enough? > > > > maybe the 2nd sentence change to > > > > The IAOC Chair does not represent the IAOC (unless directed > > to do so by IAOC consensus) and does not represent the IETF. > > > > "no formal duty" leaves the IAOC chair to do so anyway and it > > would be good, in the same place, to say that the IAOC chair > > does not represent the IETF > > Yes. "no formal duty" implies that all sorts of representations > can be made and done, it just does not _require_ the Chair to do > it. As Margaret points out, large dragons have walked through > smaller loopholes in the IETF. Scott's proposed sentence is > _much_ better. > So why not: The IAOC Chair does not represent the IAOC (unless directed to do so by IAOC consensus) and does not represent the IETF. The IAOX chair also does not erpresent: - The IESG - The IAB - The IPCDN WG - The IRTF - The UN - The ITU - The ITU-T SG4 etc etc tec Of course I am kidding... but I think the current text is fine. (my personal opinion of course). Bert > john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
bert asks: > The current text in section 3, 1st para states > The IAOC consists of volunteers, > does that not say enough? I'd say no - volunteers can get paid in some cases Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Adminrest: BCP -03: Compensation for IAOC members
Scott reponds to Jonne:
>
> Jonne asks:
> > would
> > x.x Compensation for IOAC members
> > The IOAC members shall not receive any compensation (apart from
> > reimbursement of expenses) for their services as members of the
> > IOAC."
> >
> > do the trick then?
>
> works for me
>
personal opinion:
Not for me. It seems to make it autotmatic that IAOC members DO receive
reimbursement for expenses. I think I can live with the fact that thye
may get it in special circumstances, but I do not like the idea
that text suggests that it is normal to reimburse them.
The current text in section 3, 1st para states
The IAOC consists of volunteers,
does that not say enough?
Bert
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Jonne asks: > would > x.x Compensation for IOAC members > The IOAC members shall not receive any compensation (apart from > reimbursement of expenses) for their services as members of the > IOAC." > > do the trick then? works for me ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Brian et al., would " x.x Compensation for IOAC members The IOAC members shall not receive any compensation (apart from reimbursement of expenses) for their services as members of the IOAC." do the trick then? (Modified from the ISOC by-laws.) I really do believe that at least the fact that the IOAC members are not payed for their services should be documented. Cheers, Jonne. On Sun, 2005-01-02 at 12:20, ext Brian E Carpenter wrote: > John C Klensin wrote: > > > > --On Thursday, 30 December, 2004 11:21 -0800 EKR > > wrote: > > > > > >>"Soininen Jonne (Nokia-NET/Helsinki)" > >><[EMAIL PROTECTED]> writes: > >> > >>>I admit that I maybe have too much a view point of someone > >>>working for a relatively large company. I try to approach > >>>this from a position where the IAOC itself does not become a > >>>significant cost for IASA. > >>> > >>>However, as these are the people that are responsible for > >>>setting the budget and supervising the finances of the IASA > >>>and there is no real owner to control the expenses it would > >>>be clearer to have the IAOC members being responsible for > >>>their own expenses. > >>>... > >> > >>Jonne, > >> > >>The argument you're making here is for a policy that IAOC > >>members should be responsible for their own expenses. That's a > >>perfectly reasonable policy, but the course of action you're > >>arguing for is to write it into the BCP so that it can't be > >>changed without extraordinary difficulty. Can you explain why > >>you think that that's necessary? > > > > > > EKR has now tried to make this point several times, and others > > don't seem to be hearing him, so let me try and, in the process, > > provide an additional data point. > > > > I think it is key that this is a management decision, not > > material for the BCP. The right way to deal with this, IMO, is > > the way we have (apparently) agreed to handle other details, > > i.e., to have the BCP charge the IAOC with coming up with a > > policy and making that policy known in the community. Were that > > policy to be, or become, abusive, then it needs to be fixed by > > (or with) the IAOC. But let's not lock a specific, perhaps > > over-specific, policy into the BCP. > > > > In case anyone doesn't know, IAB and IESG members, and probably > > others, have occasionally been reimbursed for travel expenses to > > meetings where they were representing the IETF and no other > > source of funds was available. If I recall, travel expenses to > > IETF meetings have occasionally, although I think very rarely, > > been reimbursed as well. When it has been done, those expenses > > have been covered out of IETF Chair discretionary funds provided > > by ISOC. The reimbursements have not been widely publicized, I > > think, out of consideration for the privacy of the people > > involved. The new IASA disclosure rules would, I believe, > > require at least an accounting of the total amounts of money > > expended in this way. But going further than that could, IMO, > > hurt our ability to operate effectively, and to get the best > > people to key meetings (rather than just the best-supported > > people) and we should be careful to not shoot ourselves in the > > foot in this area. > > Exactly. If for whatever reason a person who doesn't have corporate > support gets appointed to the IAOC, we mustn't have a rule that > prevents that person from being reimbursed for legitimate expenses. > The rule that Jonne cited for ISOC Trustees covers that nicely. > > The principle that IAOC members donate their time might be > worth writing down, but expenses are an operational matter. > > Brian -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
Harald Tveit Alvestrand wrote: ... Making IETFers suffer or not because of the weather didn't factor into the equation. Honoring previous promises on dates, getting a sponsor for a non-US meeting, and finding a location that was likely to work for the IETF to get work done did. And thankyou for that. That the result is a trip to one the nicest cities in the world is a happy coincidence, of course, but your three criteria are the important ones. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: BCP -03: Special audits
Brian, On Sun, 2005-01-02 at 12:24, ext Brian E Carpenter wrote: > Jonne, > > Soininen Jonne (Nokia-NET/Helsinki) wrote: > > Hi, > > > > sorry to tune in late, but keeping up with all the mails that are going > > around I needed a vacation at the place of my in-laws... > > > > I think the issue of a yearly audit has been solved already in the past > > (Issue 721). However, I think that there is no mention of a special > > audit outside the yearly. Special audit - as I understand it - is an > > audit that is done by an auditing company _not_ being the one usually > > used in the circumstances where there is a doubt that the IAD and/or the > > IOAC have used the funds if the IASA improperly. This is a case that > > doesn't happen often, but... > > > > Normally, in a company, such audits are decided by the owners of the > > company. So, rules in which circumstances such audit is merited is > > normally not written down. However, as here is no clear owner, maybe > > such a rule should be written down. > > > > Do people understand the issue that I am raising? > > Yes Good. > > > Do people agree with > > me? > > No, because since by definition the circumstances would be special, > I don't see how we can write down a general rule. It's simply one of the > things that could happen during an appeal under section 3.4. What I was maybe more proposing was to have in writing who can order a special audit. For instance, can IAB, IESG, or the ISOC BoT order it? Cheers, Jonne. > > Brian -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
--On Monday, 03 January, 2005 11:58 +1100 Dassa <[EMAIL PROTECTED]> wrote: >|> -Original Message- >|> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >|> On Behalf Of Theodore Ts'o >|> Sent: Monday, January 03, 2005 11:20 AM >|> To: Glen Zorn (gwz) >|> Cc: 'Iljitsch van Beijnum'; 'IETF Discussion' >|> Subject: Re: Excellent choice for summer meeting location! >|> >|> Shrug I've always liked Minneapolis, myself. I've >|> always considered it a great place for an IETF meeting. > > Australia isn't bad in August :). Perhaps some thought could > be given to holding some meetings in more regional areas also, > not just major cities. > > Darryl (Dassa) Lynch (who lives out in the boondocks of NSW > Australia). Dassa, For better or worse, we've had a preference for locations close to major airports with significant international connections. We haven't been consistent about it (note, e.g., San Diego), but, unlike that other organization whose name starts with "I" (not IEEE, Glen), we have considered it a really bad thing if most of the attendees have to spend two days getting to and/or from a meeting: turning a five-day meeting into an eight- or nine-day one is really hard on those who have other things to do besides going to meetings.I have no idea how the boondocks of NSW would fall on that criterion, but it is what has kept us near or in fairly major cities. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call on Language Tags (RE: draft-phillips-langtags-08)
Hi.
I have been following the extensive discussions of this subject
on the IETF and Language-Tags lists (somewhat over 100 relevant
messages by my rough count, although with the vast major of them
from around five participants). I note that much of it has not
been explicitly copied to the IESG list. For a number of
reasons, I've deliberately avoided making public comments to
date, but want to summarize some reactions before the Last Call
closes.
(1) I had two key concerns when Harald asked me to look at an
early version of this draft. They continued with the first last
call version, and a still concerns with this version. They
were and are:
(i) It is significantly more complicated than RFC 3066,
which it proposes to replace. While this is clearly an
interesting intellectual exercise, that additional
complexity is not clearly justified. I.e., if we are
going to replace a standard that is in
(apparently-successful) use with one that is more
complex, the added complexity should be strongly
justified in terms of requirements and problems being
solved.While section 6 of the current draft provides
some of the relevant motivation, it is not nearly strong
enough, IMO, to justify the replacement.
(ii) The notion of "converting" an IANA registry (see
Appendix C) has little precedent in the IETF or in IANA
and I would suggest that we do not have a good track
record for such conversions. The authors propose to
maintain the existing registrations in the existing
registry but not add new ones there. The resultant
status of standards-track documents that reference 3066
and its registry is unclear. Presumably, those
documents would need to be revised and re-processed to
update them to reference the new spec and registry and
implementations that are non-conformant to the new rules
would need to be changed. From an IETF procedural
standpoint, that would require replacing at least some
documents that are now at Draft Standard with new
Proposed Standards, which has been a major source of
user and implementer confusion. It is something we have
done when we have to, but the justification does not
appear to be present in this document
(iii) As the section above implies, and as has been
pointed out on the list, this specification is not
precisely upward-compatible with the specification of
RFC 3066. The document claims otherwise, then proceeds
to point out the incompatibilities (e.g., if it were
completely upward-compatible, registry conversion would
not be needed). That situation, again, should pose a
very high level of requirement for justification of the
change.
(2) Some days ago, the authors indicated that they were
producing and posting a new version of the draft in response to
some of the on-list comments. Some of those comments were
quite substantive, others probably not. That new draft has not
yet appeared; I suggest that, if any of the changes might be
substantive, it will require a new round of community review to
determine whether any changes that have been made have a
negative impact on requirements or other details that were
previously acceptable and to identify any comments that were
withheld pending the new draft. This is particularly important
since the document proposes to supercede and replace an existing
BCP and IANA registry that are in active use. I.e., this is
going to need yet another Last Call.
(3) Rather than moving to an almost-unprecedented third Last
Call (with more to come if this process is to continue as it has
proceeded in the past), I'd like to offer three alternate
suggestions. I hope these are mutually exclusive.
(i) Since we have no "Next-Best Current Practices"
category, publish this as an Informational Document,
moving it to BCP (and to "obsoletes 3066") only when
revisions of all documents that reference the 3066
registry (that includes not only IETF standards-track
and BCP documents, but also the ICANN IDN registration
procedures document and perhaps others) have been
written and have achieved community consensus.
(ii) Revise the introductory material in this document
to indicate that it is an alternative to 3066 that may
be more appropriate for some purposes and identify at
least some of those purposes. Revise the "registry
conversion" material to provide a way to seed the new
registry and, if appropriate, providing for simultaneous
registration in both registries for new submissions.
Based on those changes, indicate that it modifies
("updates") 3066, rather than obsoleting it. Most of
RE: Excellent choice for summer meeting location!
--On lørdag, januar 01, 2005 18:20:02 -0800 "Glen Zorn (gwz)" <[EMAIL PROTECTED]> wrote: Ha Ha. You (and others) have made the point quite well that the majority of IETFers are probably hardy enough to suffer through the week without actually dying. So what? The real question is why we must suffer at all injecting the opinionating with some facts. - the dates for future IETF meetings are set in advance, due to extensive arguments by IETFers and other standards organizations that having the IETF schedule their meetings on short notice and against other meetings is a Bad Thing. - when France Telecom suggested that they could sponsor one of the 2005 IETF meetings, none of the 2005 meetings had sponsors. So they (France Telecom and Foretec) started investigating sponsoring the spring meeting. - It turned out that at those dates, there were no suitable facilities to be found in places where they wanted to sponsor the meeting. So they moved on to the next meeting - August. - After some searching, a suitable venue was available in Paris. I received the suggestion (with some alternatives), and said that I found this venue acceptable. Making IETFers suffer or not because of the weather didn't factor into the equation. Honoring previous promises on dates, getting a sponsor for a non-US meeting, and finding a location that was likely to work for the IETF to get work done did. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #727: Section 2.2, 4, & 7 - Miscellaneous & editorial
John C Klensin wrote: --On Sunday, 02 January, 2005 08:19 -0500 Scott Bradner <[EMAIL PROTECTED]> wrote: brian asks Perhaps we do indeed need to explicitly limit the IAOC Chair to chairing the IAOC. But we almost do - the following paragraph says: The chair of the IAOC shall have the authority to manage the activities and meetings of the IAOC. The IAOC Chair has no formal duty to represent the IAOC, except as directed by IAOC consensus. Isn't this enough? maybe the 2nd sentence change to The IAOC Chair does not represent the IAOC (unless directed to do so by IAOC consensus) and does not represent the IETF. "no formal duty" leaves the IAOC chair to do so anyway and it would be good, in the same place, to say that the IAOC chair does not represent the IETF Yes. "no formal duty" implies that all sorts of representations can be made and done, it just does not _require_ the Chair to do it. As Margaret points out, large dragons have walked through smaller loopholes in the IETF. Scott's proposed sentence is _much_ better. Sure. Margaret Wasserman wrote: > At 11:37 AM +0100 1/2/05, Brian E Carpenter wrote: > >>The chair of the IAOC shall have the authority to manage the >>activities and meetings of the IAOC. The IAOC Chair has no formal >>duty to represent the IAOC, except as directed by IAOC consensus. >> >> Isn't this enough? > > > Yes, I think so. That is why I'd prefer to remove the much more > open-to-interpretation description of these duties that says that the > IAOC Chair will have all of the responsibility and authority "normally > associated with" this position. In the IETF an extensive amount of > power, authority and rights have been attributed to various Chair > positions that go well beyond chairing committee meetings and > representing the consensus of a well-defined group. Well, let's not get diverted here from the IAOC chair. With the text as suggested by Scott, I can't see any harm in removing the earlier phrase as Margaret suggests. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
ext Glen Zorn (gwz) wrote: Ha Ha. You (and others) have made the point quite well that the majority of IETFers are probably hardy enough to suffer through the week without actually dying. So what? The real question is why we must suffer at all (I'm actually rather surprised that Phoenix has not become the permanent summer choice -- 130F would certainly keep us in the hotel where (apparently) we belong. Yeah, but that's dry heat. It's not that bad really. Cheers, Aki ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
