Re: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
> [EMAIL PROTECTED] scripsit: > > I know of two other wrinkles in the RFC 1766 world: > Are you aware that RFC 1766 has been obsolete for four years now? Of course I am. > > (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact > >sufficiently different languages that a primary tag match should not be > >taken to be a generic match. > The same is true of the various registered zh-* tags. Yes, forgot to mention that one. It is actually different and more important in that the use-cases aren't the same as those for sign languages. > > (a) Extension tags appear as the first subtags, and as such have to > >be taken into account when looking for country subtags. > Finding country codes is straightforward: any non-initial subtag of two > letters > (not appearing to the right of "x-" or "-x-") is a country code. > This is true in RFC 1766, RFC 3066, and the current draft. On the contrary, in RFC 3066 the rule is "any 2 letter value that appears as the second subtag is a country code". The rule in the new draft is either the formulation you give above or "any 2 letter value that appears as a subtag after the initial subtag and some number of 3 and 4 letter subtags". These aren't the same. > > (b) Script tags change the complexion of the matching problem significantly, > >in that they can interact with external factors like charset information > >in odd ways. > Can you clarify this? Charset information neither specifies nor necessarily > restricts (except in text/plain) the script used to write a document. And what if you're dealing with text/plain, as many applicationss do? Just because something doesn't necessarily do something doesn't mean it never does it. > > (c) UN country numbers have been added (IMO for no good reason), requiring > >handling similar to country codes. > They provide for supranational language varieties and for stability in > country codes which is inappropriate for ISO 3166 alphabetic codes (which > are codes for country *names*). I'm aware of what they provide (although I see no explanation of this in the draft). I'm just not convinced that their addition is warranted. > > The bottom line is that while I know how to write reasonable code to do RFC > > 1766 matching (and have in fact done so for widely deployed software), I > > haven't a clue how to handle this new draft competently in regards to > > matching. > The draft describes only the RFC 1766 (3066) algorithm, without excluding > other algorithms to be defined later. Well, maybe I'm missing something obvious, but I see nothing in RFC 3066 that qualifies as a description of a matching algorithm. The new draft does include such a description in section 2.4.2 - an improvement - but leaves any number of details open. And we all know where the devil lives. Side note: I don't think item 4 really belongs in the list in section 2.4.2. It is a warning to implementors, not part of the matching mechanism. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Language Tags: Response to a part of Jefsey's comments concerning the W3C
At 03:11 04/01/2005, Addison Phillips [wM] wrote: I'm not going to respond to most of Jefsey's comments. However, wearing my W3C hat for a moment* Thank you for that. 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. ??? I am not sure I understand. Every network user application is a consumers of language support. If there is no W3C official position yet, why not to follow under IAB guidance (or to review) the charter I proposed yesterday, in an IETF way everyone could participate, and to have all these applications supported one shot in working on a linguistic ontology where each language instance would be documented by an ad hoc authoritative source. Otherwise it could not be the standard you wish. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, specifications, and extensions
At 00:55 05/01/2005, Addison Phillips [wM] wrote: The characterization of this draft as "controversial" because two or three people object to *any* change of RFC 3066, regardless of any evidence presented of evolving needs and careful consideration thereof, is incorrect. Dear Addison, your draft is not controverted for bettering RFC 3066 but for not bettering it enough, in an interapplication concerted way, for the standard you want your draft to become. I cannot respond for John or Christian. But I will document for the few I represent. Let's let the IESG decide on that. I am sorry. The IESG does not decide about the document, but about the existence of a consensus. We tried to get one. But you decided not to respond. So, there is *no* consensus. There are even *strong* political (Governmental) oppositions. I document this below. Asking the IESG to abandon the Last Call because you don't like the draft or because you don't care for our responses to you is, frankly, odious. Let the process play out. Please do not take it that way. No one is odious. We are here to loyally help. And find the best solution together. What would be unfair would be to impose on us something. There MUST be a consensus. Also, think that no one has had the time to think over your Draft, during the years end period. And you refuse to discuss it. We supported you. I still do provided your Draft only claim to be an extension of RFC 3066, for the applications wishing to use it, since several say it cannot be an RFC for Information. The issue and the document confusion and paucity are too important for the world, for the IETF and for my 27 years long fight for the users, for me to accept it to be an Internet standard. If we live the process play out, hopefully the Last Call will be abandoned (actually I understand you abandoned it since you have a -09.txt none one has seen). If you accept to discuss the most important objection, may be we could reach a quick consensus. But your "I will not comment most of Jefsey's points" is not serious. Everyone could read them and several commented them positively off line. Let understand the (several) Governments and specialized organizations concerns. I reported (please correct me if I was wrong) them: 1. the Internet standard process permits IAB Chartered IETF WGs to propose Drafts to the review of the IESG which examines them, may call on experts and has a Last Call before endorsing them as RFCs. It also permits groups of individual to propose private Draft to the IESG. 2. there is an RFC 3066 which documents languages in giving them a language+country-code tag. This tag is used in applications like the Web to know the language of a page. Special language tags can be registered with the ICANN's IANA. All the tags build a directory of the languages of the countries of the world. 3. there is a great need for a better multilingual support. A multilingual Internet is both a technical priority and a WSIS major priority. The IAB has not acknowledged this in listing its R&D funding priorities in RFC 3869. 4. a group of private specialists proposes to get accepted by the IESG a replacement of the RFC 3066. It adds the consideration of the scripting together with the language and the country. It adds more stringent registration rules for the language tags and wants to be the Internet standard to designate languages. This means that the resulting of directory of language will be the unique reference for the Internet. 5. the Last Call debate has shown that the authors want only to consider a unique language tag to be registered for the national written expression of a language, without adding the possibility to document their various usage and their documenting authorities. This means there will be a single Internet scripted language per country in Search Engines, Web Pages, Domain Names, Web Services, on-line literature, e-learning, e-commerce, e-government, protocols, technical translations, etc. 6. I explained that we work (AFRAC, an experimental national reference center) on the complimentary concepts of a Multilingualism ontology considering scripting and vocal language instantiations, their descriptors list, semantic, filtering algorithms and possible authoritative cultural intergovernance. That we supported the effort engaged by the author of the draft but found their text premature as a projected standard. The first answers I received (we were in a vacations period) include the following comments/questions: - there is at least two Internet scriptings : upper/lower case and case indifferent. Are they supported? - there is different character sets: scientific language includes Greek characters, administrative do not. how do they address that? - is it compatible with the IDNs tables which will already designate the Web page access and be used in its links? - who is to register that unique definition of our national language? - if this wa
Re: IDN and language
At 23:37 04/01/2005, John Cowan wrote: John C Klensin scripsit: I know that -- I did read 3743 first. But in that case, whatever did you mean by "ICANN has created a recommendation [...] that languages not be mixed within a label"? The first question (see may yesterday mail) is to define what we are talking about. What is a language. You do not talk about the same thing as ICANN. How could it? There is no requirement that there be a table for every possible language tag, after all; all existing language tags remain valid. These tables are just tagged content like any other, though the application of the tag is different from the usual application. I do not understand. What is the "usual application" ? We are talking about a standard? jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
Dassa wrote: Actually I find it hard to understand Adelaide having issues with accommadation unless there was another major event at the same time. How does it cope with motor sport events, they used to hold some there didn't they? Hotels don't like blocking all of their rooms to one event so you will never get all of their rooms.Count yourself lucky to get 50% of them. Also some have standing bookings, such as airline flight crews, etc., that cut down their actual usable capacity. Of course the secretariat know all of this. For motor sport events there is a smaller percentage of non locals, more people in a single room and they are happy to travel further. Also I recall in the first years of the Formula One Grand Prix the GP office was organising home stays in addition to booking accomodation over 50km from the event. Not exactly ideal for an IETF. When the Ring Cycle was in town all the hotels kept their rates at rack rate and insisted that all bookings conform to the cycle. This made it unworkable even though the convention centre was available. Note Adelaide has more hotel beds now than in 2000 and while the building work at the Convention Centre is finished it build more exhibition space rather than more plenary rooms. In short, unless you have tried to do this you probably don't realise how difficult it is to find a site suitable for the IETF. Mark. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, specifications, and extensions
The characterization of this draft as "controversial" because two or three people object to *any* change of RFC 3066, regardless of any evidence presented of evolving needs and careful consideration thereof, is incorrect. Let's let the IESG decide on that. Asking the IESG to abandon the Last Call because you don't like the draft or because you don't care for our responses to you is, frankly, odious. Let the process play out. None of the comments I've seen from you or others can, in fact, be characterized as other than a subjective judgment of the draft or a criticism that applies to the existing draft. It *may* be true that your subjective judgments are correct, but then again, it may be that yours is an outlying minority view, at least once folks have reviewed the draft, arguments in its favor, and responses to comments on it. Let's trust in the process and the IESG to decide how to proceed: present your objections and comments. Please allow for discussion as appropriate, possibly on the languages list instead of on the ietf list, if you prefer. Then, if one party or the other disagrees with the result, the aggrieved can all consider the various appeals processes open to the losers. I'm sorry about the volume, but don't know how else to deal with the complex arguments presented. 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. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of John C Klensin > Sent: 2005å1æ3æ 18:41 > To: Christian Huitema > Cc: ietf@ietf.org; [EMAIL PROTECTED] > Subject: 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-languages mailing list > [EMAIL PROTECTED] > http://www.alvestrand.no/mailman/listinfo/ietf-languages ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
On 4-jan-05, at 19:33, Stephen Sprunk wrote: A sponsor might find that hotels and meeting rooms may be cheaper in a smaller city, but that has to be balanced against the cost of attendees' flights, availability of venues, and other suitability factors. It would be interesting to see a breakdown of these factors. As far as I can tell, this doesn't happen (at least not explicitly). It looks to me that meeting venue selection is by and large dictated by previous experience and assumptions. (And in many instances by what's cheapest/easiest for "the organization".) Most major world cities are airline hubs with nonstop international flights; Assumption. For instance, in Europe the cities are much closer together, so medium-sized cities don't necessarily have an airport (either at all or one with intercontinental flights). However, we do have good railroads so generally, this isn't much of a problem. (For instance, the entire province of South Holland, with the cities The Hague and Rotterdam in it, has 3.4 million inhabitants but only a tiny 1 runway civilian airport. But with the train you're at Schiphol (Amsterdam) airport in 30 - 45 minutes.) However, those IETF members who cannot attend (particularly since you've increased the cost of doing so) might not be able to participate if the venue doesn't have sufficient bandwidth to support streaming the meeting. Bandwidth is a non-issue. Any place in the developed world that's big enough has fiber or is close enough to fiber for a microwave hop. There are many alternatives for the current way IETF meetings are organized. For instance, the summer meeting could be done at a university. The bigger ones should have enough space. That would probably be very cheap. Off-season tourist spots are less radical but also interesting. But the question is: what are we trying to optimize for? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
John C Klensin scripsit: > I suppose there are always exceptions. In particular, the > recommendations of RFC 3743 are about tables of characters, not > dictionary lookup. I know that -- I did read 3743 first. But in that case, whatever did you mean by "ICANN has created a recommendation [...] that languages not be mixed within a label"? > If, however, a domain decided to adopt a > canonical dictionary and lookup in it as a registration > criterion, that rule would be perfectly enforceable. Certainly. But that is not the same as saying "languages [SHOULD] not be mixed in a label." That is a stricture about linguistic entities, not about entries in a dictionary. > Other issues occur if the writing order of > characters in a language obeys specific rules and one chooses to > enforce them (a potential issue with, e.g., Hangul, although, > again, the choice of whether or not to try to enforce is up to > the registry). This is even more confusing. What languages do *not* impose a specific writing order on their characters? > It is not clear that the current proposal is much better than 3066 > for handling those cases, but I wonder if anyone has carefully > evaluated whether it would make things worse. How could it? There is no requirement that there be a table for every possible language tag, after all; all existing language tags remain valid. These tables are just tagged content like any other, though the application of the tag is different from the usual application. -- XQuery Blueberry DOMJohn Cowan Entity parser dot-com [EMAIL PROTECTED] Abstract schemata http://www.reutershealth.com XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
--On Tuesday, 04 January, 2005 12:52 -0500 John Cowan
<[EMAIL PROTECTED]> wrote:
> John C Klensin scripsit:
>
>> Returning to the DNS/IDN situation, ICANN has created a
>> recommendation for all TLDs, and a requirement on at least
>> some gTLDs, that languages not be mixed within a label and for
>> registration and use of tables similar to those recommended by
>> RFC 3743.
>
> This regulation is going to be completely unenforceable, since
> with a few exceptions (hexagonal French), languages do not
> have bright-line rules saying what words they do and do not
> contain. Are we to be in the position of saying that
> eigenvector.com may be registered (and is) because the word
> appears in dictionaries, whereas eigenevent.com is ruled out
> because it "mixes" English and German?
John, I am sure that ICANN would welcome your participation as
the various rules/ guidelines evolve -- those rules are not an
IETF problem, even though changes to the standard that is used
to label them might be. One of the things their processes have
in common with the IETF is that they prefer that people actually
try to read and understand documents before attacking them, but
I suppose there are always exceptions. In particular, the
recommendations of RFC 3743 are about tables of characters, not
dictionary lookup. If, however, a domain decided to adopt a
canonical dictionary and lookup in it as a registration
criterion, that rule would be perfectly enforceable. I'd
recommend against it for many reasons, but this would be more or
less up to them.
> Forbidding the mixing of scripts is another matter, although
> in fact some languages are written using more than one
> (Unicode) script.
Whether those languages are a problem or not in the DNS context
depends on whether one wishes to permit a single label to use
both (or all three in at least a few cases I know of) scripts.
Again a per-registry decision and again perfectly enforceable
either way. Other issues occur if the writing order of
characters in a language obeys specific rules and one chooses to
enforce them (a potential issue with, e.g., Hangul, although,
again, the choice of whether or not to try to enforce is up to
the registry). But one of the notational problems with using
3066 would be a rule that one can have a label that contains the
characters of a given language written in, e.g., either a
modified Arabic script or a modified Cyrillic one but not in a
modified Roman ("Latin") one. Another issue arises when one
wants to permit a character collection that includes the
characters from a given script that are used by two separate
languages -- not all of the characters of that script, but
exactly those characters that fall into the union of the
characters from the script used by the relevant languages. It
is not clear that the current proposal is much better than 3066
for handling those cases, but I wonder if anyone has carefully
evaluated whether it would make things worse.
john
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
Comments inline as appropriate. |> -Original Message- |> From: Stephen Sprunk [mailto:[EMAIL PROTECTED] |> Sent: Wednesday, January 05, 2005 5:33 AM |> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'John C Klensin'; |> 'IETF Discussion' |> Subject: Re: Excellent choice for summer meeting location! |> |> Thus spake"Dassa" <[EMAIL PROTECTED]> |> > |> -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? |> > |> > Large corporations also deal with the regional cities, PR coverage |> > would still be effective and possibly more positive. I'm not sure |> > that sponsors would take the location into too much account but may be |> > influenced by a lower spend. It is an outreach gesture that may |> > attract interest and additional participation. |> |> If the IETF's goal for meetings was to attract the press or |> general public, that might be a valid point; AFAIK, it is not. A subsidiary goal would always be to attract press if participation is to be encouraged. Building up knowledge of the IETF within the Internet using general public is also worthwhile. If more people knew of the IETF and the work it accomplishes then they would be less inclined to consume sub-standard offerings and have a clue when it comes to making purchase decisions. |> A sponsor might find that hotels and meeting rooms may be |> cheaper in a smaller city, but that has to be balanced |> against the cost of attendees' |> flights, availability of venues, and other suitability factors. Certainly true. |> > |> 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. |> > |> > No, that is the perception that is often quoted and the reason given |> > but is not always fact. I would normally travel less than most people |> > working in a capital city. |> |> During the meeting, that might be true, but the concern is |> getting _to and from_ said city. Unless the meeting is held |> in SJ or DC, it's reasonable to assume that 99% of regular |> attendees are from out of town. If we accept that as a given and ignore the reasons for the statistic, why hold meetings elsewhere? What is the motivation for holding meetings in countries other than the States or other cities within the States? |> Most major world cities are airline hubs with nonstop |> international flights; that means most attendees can get |> there in one hop and the remainder can usually get there in |> two. For a small city, you are automatically adding another |> flight to nearly all attendees, and typical airline pricing |> means flying to a "small" city will double (or more) the |> cost of tickets. I don't understand how adding another hours flight doubles the cost of a ticket. Either the main flights are very cheap or some places have extremely expensive internal travel. But a valid point. I will have to look into ticket pricing and see if this claim is justified. If it is, it means the overall expenses no matter where the location would most likely end up being similar. |> And that's assuming that city even has enough air service to |> meet the sudden demand; there are places in the US with |> 100k+ residents that have 150 seats/day (or less) of air |> service -- assuming they have an airport at all. |> In such cases, nearly all attendees would end up flying to a |> major city and then drive down, adding two days to the trip. Careful consideration would have to be given to any touted location to ensure facilities could handle the demand. Even major airports can have issues with an unexpected increase in demand. |> > The benefit would be those with sub-standard connections would have |> > the opportunity to participate where otherwise they might not have the |> > opportunity. |> |> Only for those people actually living in that small city, |> which not statistically likely to include any IETF members |> other than those employed by the sponsor. I would be thinking those within the region, not just the host city would be more likely to make the short trip to attend. A lot of people are more willing to travel within their own country than overseas. |> However, those IETF members who cannot attend (particularly |> since you've increased the cost of doing so) might not be |> able to participate if the venue doesn't have sufficient |> bandwidth to support streaming the meeting. I would think other savings would offset any increases in travel costs so the overall cost for attendance would be similar. As mentioned previously, even regional cities usually have sufficient bandwidth at the city cent
Re: Excellent choice for summer meeting location!
Thus spake"Dassa" <[EMAIL PROTECTED]> > |> -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? > > Large corporations also deal with the regional cities, PR coverage > would still be effective and possibly more positive. I'm not sure > that sponsors would take the location into too much account but > may be influenced by a lower spend. It is an outreach geasture > that may attract interest and additional participation. If the IETF's goal for meetings was to attract the press or general public, that might be a valid point; AFAIK, it is not. A sponsor might find that hotels and meeting rooms may be cheaper in a smaller city, but that has to be balanced against the cost of attendees' flights, availability of venues, and other suitability factors. > |> 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. > > No, that is the perception that is often quoted and the reason > given but is not always fact. I would normally travel less than > most people working in a captial city. During the meeting, that might be true, but the concern is getting _to and from_ said city. Unless the meeting is held in SJ or DC, it's reasonable to assume that 99% of regular attendees are from out of town. Most major world cities are airline hubs with nonstop international flights; that means most attendees can get there in one hop and the remainder can usually get there in two. For a small city, you are automatically adding another flight to nearly all attendees, and typical airline pricing means flying to a "small" city will double (or more) the cost of tickets. And that's assuming that city even has enough air service to meet the sudden demand; there are places in the US with 100k+ residents that have 150 seats/day (or less) of air service -- assuming they have an airport at all. In such cases, nearly all attendees would end up flying to a major city and then drive down, adding two days to the trip. > The benefit would be those with sub-standard connections would > have the opportunity to participate where otherwise they might > not have the opportunity. Only for those people actually living in that small city, which not statistically likely to include any IETF members other than those employed by the sponsor. However, those IETF members who cannot attend (particularly since you've increased the cost of doing so) might not be able to participate if the venue doesn't have sufficient bandwidth to support streaming the meeting. > It would also assist with focusing on the issue of increasing > broadband uptake and opportunities. It would certainly be a > good PR exercise. It's not the goal of IETF meetings to do PR exercises, nor would one week of demand be enough to convince the local telco or regulators that increased deployment of broadband is necessary. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ 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 Mark Prior |> Sent: Wednesday, January 05, 2005 12:22 AM |> To: [EMAIL PROTECTED] |> Cc: 'IETF Discussion' |> Subject: Re: Excellent choice for summer meeting location! |> |> Dassa wrote: |> |> > |> -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? |> > |> > A lot of regional centres are geared to large numbers of tourists/visitors. |> > As for expensive and overbooked, I find most large cities have prices |> > two or three times those in regional centres for accommadation and as |> > any use of a regional centre would be a big bonus to the host city, |> > there is scope for negotiation and I'm sure additional price cuts. |> |> Not many regional cities would have the conference |> facilities that will cope with an IETF, it's not your normal |> conference that just needs a single large plenary hall. This may be the biggest issue. True a lot of regional cities wouldn't have the facilities. Some do however. It may mean that all the conference rooms are not at the same location but the distance between them would not be great. Usually within a 5-10 minute walk. I can think of at least two regional cities in NSW that could cope fairly easily and I'm sure there would be more in Australia. |> I will also note that in 2000 Adelaide, a city of around 1 |> million people, struggled for hotel rooms given that people |> not associated with the IETF also wanted hotel rooms in the city :) True, in a regional city, not everyone would be able to stay in the one place and would be scattered around the city at various hotels, motels and other accommadation. I know of a few regional cities that can handle the numbers talked about so far, there are sure to be others. The timing would have to be right so other major events are not being held at the same time but that sort of problem exists for capital and major cities also. For instance Tamworth has a massive influence of people for the Country Music Festival. It is hard to find acccommadation there unless booked well in advance. I have a chat to our local Tourism Officer and see just what sort of figures are available for some of the regional cities with regard to facilities and how many visitors they get/can handle. It may be interesting. Actually I find it hard to understand Adelaide having issues with accommadation unless there was another major event at the same time. How does it cope with motor sport events, they used to hold some there didn't they? There would certainly be a bit more work in preparing for a meet such as the IETF and there may be too many issues to consider regional cities but it is a worthwhile exercise to see just what the disadvantages and advantages may be. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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: Last Call on Language Tags (RE: draft-phillips-langtags-08)
> From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] > 2. I never objected the scripting-ID. I objected that it was not given the > same importance as language and country codes. I plead (and act) for 25 > years for the support of authoritative distinctions among users contexts. > But I am not paid by a big employer. I don't have time to offer many comments. Let me say for the benefit of people that don't know much about me that up to a year ago I was not paid by a big employer, but was a volunteer working for a non-profit organization, SIL International, and it was in *that* context that I became involved in the development of ISO 639 (including being SIL liaison to the ISO 639-RA/JAC, a member of the US TAG for TC 37, and project editor for ISO 639-3), a contributor to the development of RFC 3066 and a regular participant in the activity of the IETF-languages list. > There is NO consensus in the community and huge technical, > societal, economical and political concerns. Because one does not > understand what the Draft wants to achieve, for who and how. The main > request is to clarify. There are no real objections (except to the paucity > of the proposition) but concerns. I haven't seen many requests for clarification. If that is people are wanting, then I think the authors, or others, can provide that, if it's made clear at what points clarification is needed. > > > 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. > > You respond none. Just an application level problem. I was asked to respond with examples that pertain to IETF-standard software, so that's what I did. > >I've used Chinese as one example, but there are many other cases, some > >familiar to many and some less well known > Full agreement. But this is to be done through an open and inclusive > semantic, not on an exclusive first come first serve registration basis. Which is why one of the aims of the proposed draft is to fully incorporate script IDs as sanctioned sub-tags rather than leaving individual parties to make ad hoc registrations for such distinctions. > Why do you want there would be an exclusive _unique_ matching algorithm? I have never said I want that. > We had a long talk at the end of the August Paris meeting at AUF over ISO > 639-2 and the need to aggregate language ID, scripting ID, usage > description, authoritative sources and also country codes and on the > complexity to take into account "sub-code" and private codes and to add > accidental or new descriptors in order to document venacular ways of > speaking, thinking, talking. Obviously it was a private discussion with a > few people sharing the same ideas ... May be you were there (we were the > last to leave the room and the building). I don't know. I don't recall this discussion, and I can't put a face to your name. I know I was not last to leave the room. Obviously I have ideas on those issues. 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
> From: [EMAIL PROTECTED] [mailto:ietf-languages- > [EMAIL PROTECTED] On Behalf Of John Cowan > > The whole question of what is a language, a variant or dialect of a > > language, or a suitable substitute for a language, would benefit some > > thought in any tagging scheme, though I agree the problem is not > > generally soluble. > > See the editor's draft of ISO 639-3 at http://tinyurl.com/6kky2 ... I would say that all of clause 4.2 is relevant; in addition to 4.2.1, I would especially include 4.2.2, in relation to which I have presented ideas that led to the inclusion of the Extensions subtag in the proposed draft. (I originally thought of it as a way to capture some existing registered tags as part of a consistent scheme rather than merely as ad-hoc tags, but I think it may be more generally useful as well for dealing with some of the issues regarding different perceptions of what is a language.) I'm afraid I don't have time at the moment to elaborate further. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
At 05:39 04/01/2005, Franck Martin wrote: Don't forget also: It is FULL of French! And very upset Frenchies if the IESG accepts the Draft-Phillips-language-08/9.txt as a standard to be. I suppose there could be a premiere: street riots opposing an IETF meetings :-) This would warm-up the atmosphere ! But sorry to dismay you, there is no one in Paris in August, only Chinese, Japanese and Americans, transiting Dutch and relaxing Germans. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
At 18:06 04/01/2005, John C Klensin wrote: Returning to the DNS/IDN situation, ICANN has created a recommendation for all TLDs, and a requirement on at least some gTLDs, that languages not be mixed within a label and for registration and use of tables similar to those recommended by RFC 3743. Those tables are identified by a combination of the Domain name associated with the registering TLD registry and a 3066 code. That system is not, IMO, working especially well and the 3066 code model will, I think, have to be extended to deal with some unusual situations. But, interestingly, draft-phillips... doesn't appear to solve that particular problem: what is needed is a way to specify odd mixtures of languages and/or scripts that may be appropriate to a particular zone, and that means less specificity and more linguistically-strange constructions, not more specificity and structure. The real problem is the confusion all this introduce because it is not a consensual draft by an IETF WG working along an IAB approved Charter, what is odd when the discussed RFC was authored by the IESG Chair and the private mailing list hosted under his name with the name "ietf-language" what is confusing to many. At this stage, we can only say that there is no consensus on what is discussed, on the problems to solve and the proposed solutions. But that there is no reason why there would not be such a consensus when the charter I outlined yesterday would have been carried. 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)
Dear Peter, I am sorry to comment this again. But this is a Last Call over a private proposition. There is no other forum to comment this key document for the future of the Internet. There is also no other forum to correct what you say on me. I whish to recall that the main issues are the pretence of the draft to obsolete RFC 3066 while being sometimes conflicting and to extend its scope without limit (cf. Addison Phillips comment) what would be an IESG commitment on the whole multilingual internet architecture. I wish also to underline that I agreed with you on many points during the private list discussion and private mails. At 03:58 04/01/2005, Peter Constable wrote: 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. Hopefully a few people have congregated to support the proposed draft. Now their positions are to match a consensus process. If your propositions are not harming anyone and being usefull to some there is no reason not to have a consensus. Today the consensus inclines to say that they might be harmfull and should therefore be reserved to those who need them. Concern is that this might make them irreversibly incompatible. And that the benefits (for them and others) are not clear. The target is to try to clarify. 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. I suppose I am among that "seldom" new comers. So let me comment on that: 1. I incorporated my international users need support organization in 1978 :-) 2. I never objected the scripting-ID. I objected that it was not given the same importance as language and country codes. I plead (and act) for 25 years for the support of authoritative distinctions among users contexts. But I am not paid by a big employer. 3. I objected the scarcity of possible tags 4. I objected the exclusiveness in a registration approach versus a desription approach. 5. I supported the proposed scheme as long as its scope of application was defined and not a take-over on the multiligual Internet. Last but not least, I received enough off list support to accept to spend time on this. There is NO consensus in the community and huge technical, societal, economical and political concerns. Because one does not understand what the Draft wants to achieve, for who and how. The main request is to clarify. There are no real objections (except to the paucity of the proposition) but concerns. > 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. You respond none. Just an application level problem. 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. Full agreement. But this is to be done through an open and inclusive semantic, not on an exclusive first come first serve registration basis. Next setp will be patents on languages descriptions. In ideal terms, I do not think that all of the complexity of the proposed draft is needed. So let simplify it, and let deep into the areas were complexity comes from limited possibilities. 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 p
RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
> From: Dave Singer [mailto:[EMAIL PROTECTED] > The whole question of what is a language, a variant or dialect of a > language, or a suitable substitute for a language, would benefit some > thought in any tagging scheme, though I agree the problem is not > generally soluble. These are questions that have been given some thought. No time to delve into it at the moment, however. 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
Dave Singer scripsit: > Yes, I picked off an easy example for which the 'matching' section of > the draft didn't seem adequate. This really is a tar-pit, of course. Indeed it is, which is why the draft provides only one simple algorithm (described as "the most common implementation", which it is) and explicitly allows for cleverer techniques for those who want them. > I assume that they are mutually intelligible. Among speakers of good will, yes. > The whole question of what is a language, a variant or dialect of a > language, or a suitable substitute for a language, would benefit some > thought in any tagging scheme, though I agree the problem is not > generally soluble. See the editor's draft of ISO 639-3 at http://tinyurl.com/6kky2 . This is a PDF file about 4 MB in size, so I excerpt the relevant text here (clause 4.2.1, pp. 3-4): # There is no one definition of "language" that is agreed upon by all and # appropriate for all purposes. As a result, there can be disagreement, # even among speakers or linguistic experts, as to whether two varieties # represent dialects of a single language or two distinct languages. For # this part of ISO 639, judgments regarding when two varieties are # considered to be the same or different languages are based on a number # of factors, including linguistic similarity, intelligibility, a common # literature, the views of speakers concerning the relationship between # language and identity, and other factors. The following basic criteria # are followed: # # Two related varieties are normally considered varieties of the same # language if speakers of each variety have inherent understanding # of the other variety (that is, can understand based on knowledge of # their own variety without needing to learn the other variety) at a # functional level. # # Where spoken intelligibility between varieties is marginal, the # existence of a common literature or of a common ethnolinguistic # identity with a central variety that both understand can be strong # indicators that they should nevertheless be considered varieties of # the same language. # # Where there is enough intelligibility between varieties to # enable communication, the existence of well-established distinct # ethnolinguistic identities can be a strong indicator that they should # nevertheless be considered to be different languages. # # Some of the distinctions made on this basis may not be considered # appropriate by some users or for certain applications. These basic # criteria are thought to best fit the intended range of applications, # however. -- First known example of political correctness: John Cowan "After Nurhachi had united all the otherhttp://www.reutershealth.com Jurchen tribes under the leadership of the http://www.ccil.org/~cowan Manchus, his successor Abahai (1592-1643) [EMAIL PROTECTED] issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus." ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
> ruled out because it "mixes" English and German? > Sorry I can't resist: like in EdelWeb.fr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
[EMAIL PROTECTED] scripsit: > I know of two other wrinkles in the RFC 1766 world: Are you aware that RFC 1766 has been obsolete for four years now? > (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact >sufficiently different languages that a primary tag match should not be >taken to be a generic match. The same is true of the various registered zh-* tags. > (a) Extension tags appear as the first subtags, and as such have to >be taken into account when looking for country subtags. Finding country codes is straightforward: any non-initial subtag of two letters (not appearing to the right of "x-" or "-x-") is a country code. This is true in RFC 1766, RFC 3066, and the current draft. > (b) Script tags change the complexion of the matching problem significantly, >in that they can interact with external factors like charset information >in odd ways. Can you clarify this? Charset information neither specifies nor necessarily restricts (except in text/plain) the script used to write a document. > (c) UN country numbers have been added (IMO for no good reason), requiring >handling similar to country codes. They provide for supranational language varieties and for stability in country codes which is inappropriate for ISO 3166 alphabetic codes (which are codes for country *names*). > The bottom line is that while I know how to write reasonable code to do RFC > 1766 matching (and have in fact done so for widely deployed software), I > haven't a clue how to handle this new draft competently in regards to > matching. The draft describes only the RFC 1766 (3066) algorithm, without excluding other algorithms to be defined later. -- "Clear? Huh! Why a four-year-old childJohn Cowan could understand this report. Run out [EMAIL PROTECTED] and find me a four-year-old child. I http://www.ccil.org/~cowan can't make head or tail out of it." http://www.reutershealth.com --Rufus T. Firefly on government reports ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
At 9:14 AM -0800 1/4/05, [EMAIL PROTECTED] wrote: 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, this isn't the half of it. The case you describe is actually one of the easy ones, in that it can be handled by doing a "preferred" match on the entire tag, with a "generic" match on the primary tag only having lesser precedence but higher precedence than a fallback to a default. Yes, I picked off an easy example for which the 'matching' section of the draft didn't seem adequate. This really is a tar-pit, of course. Serbo-croatian used to be a language; now it's serbian and croatian. I assume that they are mutually intelligible. Serbian is probably a better substitute for croatian than some general default (or silence), though saying this in some parts of the world might start wars. The whole question of what is a language, a variant or dialect of a language, or a suitable substitute for a language, would benefit some thought in any tagging scheme, though I agree the problem is not generally soluble. I know of two other wrinkles in the RFC 1766 world: (1) Matching may want to take into account the distinguished nature of country subtags in some way. (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact sufficiently different languages that a primary tag match should not be taken to be a generic match. (Of course this only matters if sign languages are relevant to your situation - in many cases they aren't. In retrospect I think it was a mistake to register sign languages this way.) This proposed revision, however, opens pandora's box in regards to matching. Consider: (a) Extension tags appear as the first subtags, and as such have to be taken into account when looking for country subtags. (b) Script tags change the complexion of the matching problem significantly, in that they can interact with external factors like charset information in odd ways. (c) UN country numbers have been added (IMO for no good reason), requiring handling similar to country codes. The bottom line is that while I know how to write reasonable code to do RFC 1766 matching (and have in fact done so for widely deployed software), I haven't a clue how to handle this new draft competently in regards to matching. And the immediate consequence of this is that I, and I suspect many other, implementors are going to adopt a "wait and see" attitude in regards to implementing any of this. Ned -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
Small typo: In my previous response I referred to RFC 1766 when I meant RFC 3066. Too many documents open at once, sorry. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
John C Klensin scripsit: > Returning to the DNS/IDN situation, ICANN has created a > recommendation for all TLDs, and a requirement on at least some > gTLDs, that languages not be mixed within a label and for > registration and use of tables similar to those recommended by > RFC 3743. This regulation is going to be completely unenforceable, since with a few exceptions (hexagonal French), languages do not have bright-line rules saying what words they do and do not contain. Are we to be in the position of saying that eigenvector.com may be registered (and is) because the word appears in dictionaries, whereas eigenevent.com is ruled out because it "mixes" English and German? Forbidding the mixing of scripts is another matter, although in fact some languages are written using more than one (Unicode) script. -- "And it was said that ever after, if anyJohn Cowan man looked in that Stone, unless he had a [EMAIL PROTECTED] great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame." --"The Pyre of Denethor" ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions
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, this isn't the half of it. The case you describe is actually one of the easy ones, in that it can be handled by doing a "preferred" match on the entire tag, with a "generic" match on the primary tag only having lesser precedence but higher precedence than a fallback to a default. I know of two other wrinkles in the RFC 1766 world: (1) Matching may want to take into account the distinguished nature of country subtags in some way. (2) SGN- requires special handling, in that SGN-FR and SGN-EN are in fact sufficiently different languages that a primary tag match should not be taken to be a generic match. (Of course this only matters if sign languages are relevant to your situation - in many cases they aren't. In retrospect I think it was a mistake to register sign languages this way.) This proposed revision, however, opens pandora's box in regards to matching. Consider: (a) Extension tags appear as the first subtags, and as such have to be taken into account when looking for country subtags. (b) Script tags change the complexion of the matching problem significantly, in that they can interact with external factors like charset information in odd ways. (c) UN country numbers have been added (IMO for no good reason), requiring handling similar to country codes. The bottom line is that while I know how to write reasonable code to do RFC 1766 matching (and have in fact done so for widely deployed software), I haven't a clue how to handle this new draft competently in regards to matching. And the immediate consequence of this is that I, and I suspect many other, implementors are going to adopt a "wait and see" attitude in regards to implementing any of this. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDN and language
--On Tuesday, 04 January, 2005 09:38 -0500 Bruce Lilly <[EMAIL PROTECTED]> wrote: >> One is not. Domain names are strings of characters; only >> incidentally do they spell out one or more words in one or >> more languages. I doubt whether the names "Google," "Yahoo," >> and "AltaVista" can be pinned down as belonging to one >> specific language. > > I was referring specifically to internationalized domain names > (IDN, RFCs 3490, 3491, 3492, 3743) where the on-the-wire > domain name continues to be of traditional form (ANSI X3.4 > letters,digits, and hyphen (with restrictions on combinations > and placement)), but where a certain class of names (those > beginning with "xn--") are "internationalized" and might be > presented to users in a different form (which can include > non-ASCII characters). That came about because of the > tendency to associate a domain name (tag) with a natural > language "name" or legally-registered name (trademark, etc.). > Whether one considers such associations logical or > irrational, that is what has happened. So one could have > a domain name (beginning with xn--) that is presented by > an application as "Nestlé.com". Now certainly some names, > such as your examples, Kodak, Häagen-Dazs, etc. have no > language (because they are made-up strings of characters), > but others do have a specific language. In skimming through > the RFCs mentioned above, it appears that there is now some > provision for language tagging (which was not present in > earlier versions of IDN). However, I have not thoroughly > reviewed those recent additions; therefore it should be > clear that I have not reviewed the impact of the proposed > draft changes on IDN or vice versa. Such a review should > take place (ideally before the deadline for the New Last > Call on draft-phillips-langtags-08 (tomorrow!)), but I'm > not the person to do so as I have only slight interest in > IDN (I'm one of those who considers associating a tag > with natural language and/or legally registered names to > be irrational). One potential issue is that domain names > are case-insensitive, and whether lower-case accented > characters map to/compare with unaccented upper-case > letters may be a function of language (or culture, or > political fiat). >... > I would add that there is apparently some discussion of > wreaking similar havoc on local-parts, which appear in > message-identifiers and email mailbox identifiers (STD 11). > That too should be evaluated w.r.t. specification of > language and the proposed changes. Bruce, While I'm sympathetic to many of the points you have raised, the IDN situation is not an issue except in a very narrow sense and similar situation would apply to local-parts if we ever do something there. In the IDN case, the protocols are written in terms of arbitrary Unicode strings and just about have to be -- there has never been a DNS restriction requiring that the labels be names or words in a language. The protocols apply some mapping rules that reject a few characters (and hence the labels that contain them) and change some characters into others, but the net effect is still a set of standards written in terms of strings, not languages. There has been a good deal of concern in the DNS community about the potential for deliberately or accidentially misleading users about domain names and the consequent opportunities for confusion or outright fraud. Those concerns have led to a good deal of work on restrictions about what strings can be registered, imposing, e.g., rules that the holder of one string may be the only permitted holder of a related one and rules that prohibit mixing scripts within a single label. These types of rules, especially the latter, are the "very narrow sense" mentioned above, but they have no impact on the protocols themselves. The registration rules actually differ from zone to zone and can safely do so because, to the user of the DNS, an unregistered name is an unregistered name and the distinction as to whether a name is unregistered because no one wanted it or because some subtle rule prohibited its registration is not of importance. The situation with local-parts will, most of us are convinced, work out in much the same way. There is a long history of strings used in local-parts that are not "names", "words", or otherwise bound to a particular language. Worse, different destination systems apply different internal syntax rules and interpretations to local-part strings. Protocols will need to be designed to reflect that history and avoid unreasonable restrictions. At the same time, I would expect the administrators of an given local system to impose restrictions on what local-parts parts can be used for mailboxes there (just as is often done today). Those restrictions may, in many cases, reflect assumptions about languages and/or scripts but, since they are purely local conventions, there is no need for external registration. Returning to the DNS/
Re: Adminrest: BCP -03: Compensation for IAOC members
Harald, On Tue, 2005-01-04 at 10:28, ext Harald Tveit Alvestrand wrote: > --On 3. januar 2005 07:40 -0800 EKR wrote: > > > 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. > > At at least one point in the IETF's history, there was a nomcom > interviewing a candidate for an IETF role where the candidate said that he > would take the job only if the job was compensated - he had neither an > employer willing to sponsor nor a sufficient personal fortune he was > willing to spend. > > This received serious consideration at the time, but in the end the result > of the consideration was to pick someone else. > > I'd like to reinforce EKR's point here - there should be rules for this > sort of thing - but *these do not need to be in this document*. Compensation in the form of a "salary" of the "board" (== IAOC) members is a thing that is usually written in the by-laws. Especially, if some sort of compensation is paid it is important to document how the compensation is defined in the term of actual dollars. So, I would still support the wording that Brian put forward some mails ago. Cheers, Jonne. > > My opinion. > > Harald -- 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: IDN and language
> Re: draft-phillips-langtags-08, process, specifications, "stability", and > extensions > Date: 2005-01-01 19:56 > From: "Doug Ewell" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Bruce Lilly wrote: > > Domain names and > > language tags are different types of names, used for > > different purposes, and with different scope (largely > > non-overlapping, though one might legitimately ask how > > one is supposed to determine the language of an > > "internationalized" domain name...) > > One is not. Domain names are strings of characters; only incidentally > do they spell out one or more words in one or more languages. I doubt > whether the names "Google," "Yahoo," and "AltaVista" can be pinned down > as belonging to one specific language. I was referring specifically to internationalized domain names (IDN, RFCs 3490, 3491, 3492, 3743) where the on-the-wire domain name continues to be of traditional form (ANSI X3.4 letters,digits, and hyphen (with restrictions on combinations and placement)), but where a certain class of names (those beginning with "xn--") are "internationalized" and might be presented to users in a different form (which can include non-ASCII characters). That came about because of the tendency to associate a domain name (tag) with a natural language "name" or legally-registered name (trademark, etc.). Whether one considers such associations logical or irrational, that is what has happened. So one could have a domain name (beginning with xn--) that is presented by an application as "Nestlé.com". Now certainly some names, such as your examples, Kodak, Häagen-Dazs, etc. have no language (because they are made-up strings of characters), but others do have a specific language. In skimming through the RFCs mentioned above, it appears that there is now some provision for language tagging (which was not present in earlier versions of IDN). However, I have not thoroughly reviewed those recent additions; therefore it should be clear that I have not reviewed the impact of the proposed draft changes on IDN or vice versa. Such a review should take place (ideally before the deadline for the New Last Call on draft-phillips-langtags-08 (tomorrow!)), but I'm not the person to do so as I have only slight interest in IDN (I'm one of those who considers associating a tag with natural language and/or legally registered names to be irrational). One potential issue is that domain names are case-insensitive, and whether lower-case accented characters map to/compare with unaccented upper-case letters may be a function of language (or culture, or political fiat). I would add that there is apparently some discussion of wreaking similar havoc on local-parts, which appear in message-identifiers and email mailbox identifiers (STD 11). That too should be evaluated w.r.t. specification of language and the proposed changes. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
Dassa wrote: |> -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? A lot of regional centres are geared to large numbers of tourists/visitors. As for expensive and overbooked, I find most large cities have prices two or three times those in regional centres for accommadation and as any use of a regional centre would be a big bonus to the host city, there is scope for negotiation and I'm sure additional price cuts. Not many regional cities would have the conference facilities that will cope with an IETF, it's not your normal conference that just needs a single large plenary hall. I will also note that in 2000 Adelaide, a city of around 1 million people, struggled for hotel rooms given that people not associated with the IETF also wanted hotel rooms in the city :) Mark. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
Responses inline as appropriate. |> -Original Message- |> From: Thomas Gal [mailto:[EMAIL PROTECTED] |> Sent: Tuesday, January 04, 2005 10:19 AM |> To: [EMAIL PROTECTED]; 'John C Klensin'; 'IETF Discussion' |> Subject: 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? A lot of regional centres are geared to large numbers of tourists/visitors. As for expensive and overbooked, I find most large cities have prices two or three times those in regional centres for accommadation and as any use of a regional centre would be a big bonus to the host city, there is scope for negotiation and I'm sure additional price cuts. |> -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. A reasonable sized regional centre would have some public transport. Mostly buses in Australia but a lot of regional city would be within easy walking distance anyway. For other sites, it wouldn't take much to organise some laid on transport to be available. Car rental may be an issue but not impossible if advance bookings are made. I don't know enough about other countries to comment but in Australia larger regional centres are mostly geared to handle a large influx of people for short periods, they often host district shows and other events where there may be an influx of several thousand people for a week or so. Places with large tourist attractions would also have the infrastructure to handle large numbers and they would be more than willing to put them to good use during off seasons. |> -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? In Australia there is often high bandwidth available in the regional cities but only if you are close to the city centre where the function centres and other facilities would be. It is when you get a few kilometres away that broadband is a problem. Also, broadband is still being rolled out so although available in most city centres, it hasn't reached the domestic market as yet in a lot of regional areas. |> -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? Large corporations also deal with the regional cities, PR coverage would still be effective and possibly more positive. I'm not sure that sponsors would take the location into too much account but may be influenced by a lower spend. It is an outreach geasture that may attract interest and additional participation. |> 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. No, that is the perception that is often quoted and the reason given but is not always fact. I would normally travel less than most people working in a captial city. For instance in Sydney it may take a person an hour to travel to work whilst in my city the majority can get to work in ten minutes. To travel 7 kilometres in a major city can be a real hassle and take hours but in a regional centre you may travel many kilometres in minutes. That is not to say living and working in a major city may not be more expensive. There are some things more expensive such as housing for instance that really make a difference but a lot of things such as food and entertainment may be cheaper. The employment prospectives are usually better in a major city also. |> -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 The benefit would be those with sub-standard connections would have the opportunity to participate where otherwise the
Re: Adminrest: BCP -03: Compensation for IAOC members
--On 3. januar 2005 07:40 -0800 EKR wrote: 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. At at least one point in the IETF's history, there was a nomcom interviewing a candidate for an IETF role where the candidate said that he would take the job only if the job was compensated - he had neither an employer willing to sponsor nor a sufficient personal fortune he was willing to spend. This received serious consideration at the time, but in the end the result of the consideration was to pick someone else. I'd like to reinforce EKR's point here - there should be rules for this sort of thing - but *these do not need to be in this document*. My opinion. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
