Subject: RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

From: "Peter Constable" <[email-masked]>
Date: Thu, 30 Dec 2004 12:19:15 -0800

> From: JFC (Jefsey) Morfin [mailto:[email-masked]]

> Dear Peter,
> please let focus on the discussion of draft to be approved by the IESG and
> on its role.

Eh???!! I can't imagine what on earth do you think I was talking about if not that.

> This document intends to replace RFC 3066 but does not want
> to
> take into account RFC published since the RFC 3006, the current IANA
> procedures, the work chartered in some WG, the internet architectural
> principle (RFC 1958).
> 
> There is no problem in having it been accepted for information or
> experimental. There are serious objections to get it approved otherwise.

(RFC 1958 was published since RFC 3066??!!)

Look, the IESG chair is the list administrator for the IETF-language list, and a participant in its deliberations. If there has been a serious lacuna in process for moving this draft toward BCP, I think he would have mentioned it on the IETF-languages list a *long* time ago. It was the IESG that issued the Last Call announcement, not me, not the authors of the draft, not anybody else on the IETF-languages list. It appears that IESG *is* moving it through a process toward BCP, and one can only assume they feel their process is adequate and appropriate. 

> >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.
> 
> (a) RFC 3066 was published without considering different usages of the
> proposed language tag format.

Eh???!! That is simply not true. RFC 3066 was developed with full awareness and consideration of all the usage scenarios for RFC 1766, which it replaced. RFC 3066 discusses various IETF and W3C protocols that use language tags. (Have you actually read RFC 3066?)

> (b) nor which authority would document their meanings (plural)

Eh???!! Section 2.2 clearly identifies the authorities that document the meanings of subtags. I have pointed out that there are aspects of meaning that it does not address (which, btw, are not easily resolvable), but that does not imply that RFC 3066 was published without consideration of what authorities document meanings.

> >I think we can all agree that there's no much less likelihood of someone
> >.... I suggest that we not dwell on pathological cases that we aren't
> >really likely to encounter.
> 
> This kind of thinking is not appropriate when standardizing a format.
> Julius Caesar would have though a pathological case to propose that Roman
> should speak Londinium's language.

If Romans had started speaking a variant of Londinium's language, the proposed draft could easily accommodate that situation. That is not pathological. A tag like "sr-Latn-CS-gaulish-boont-guoyu-i-enochian" is pathological. It most certainly *is* appropriate to identify what kinds of examples are or not valid, as we need to design for *valid* usage scenarios. For any given character set encoding standard, the fact that nonsense character sequences can be devised is not a determining factor in development of that encoding; the same is true here.

> >At this point, I feel confident that it is not a problem to combine
> script
> >IDs into "language" tags, and this is the consensus of the domain experts
> >that have been discussing this proposed revision for the past year and
> more.
> 
> This may mean that current reluctances to incorporate originating source
> authority, destination, format conformance, internationalization, icons
> support (and may be additional needs) could be a further consensus. I
> suggest that we save time this time.

??? You want to incorporate these things into the draft, or into language tags themselves? The latter is either not necessary or not appropriate (language tags should *not* include anything to indicate destination). As for inclusion in the draft, the proposed draft is quite clear about source authorities for subtags and about conformance; destination is out of scope and irrelevant. Internationalization? These are symbolic identifiers; they are intrinsically not localizable. Icon support??? I haven't a clue what you're talking about!

> >Not a problem: the proposed revision *allows* for the use of script IDs
> >but does not require them. In the case of audio content, one simply would
> >never include a script ID.
> 
> Accents and types of voice have been documented as necessary items. They
> could use the script and police fields ?

??? If someone needs to tag content to distinguish a particular dialect, the proposed draft can easily accommodate that. If one wants to tag content for minor linguistic details ("this utterance was spoken by someone who has a cleft palatte, who was intoxicated at the time, and uses tag-question intonation"), it is a *non goal* of the proposed draft to accommodate that level of detail as it is not appropriate to try to capture that level of ad hoc detail in a general-purpose metadata element.

> >The bigger problem you're pointing out is the limitations of using
> >suffix-truncation alone as a matching algorithm...

> This shows that language matching algorithm should not be addressed in the
> same document. I also submit that this kind of matching policy should be a
> possible decision of the user. Obviously IA rules should be mentionned.

It doesn't show that matching should not be addressed in the same document; it merely shows that one particular algorithm doesn't meet all needs. It would be possible to move all discussion of matching to another document, but I don't see any reason why that must be done. The draft discusses some general considerations and leaves plenty of room for separate specifications for particular matching algorithms for use in particular applications.

> > > Surely some types
> > > of script is indicated by the charset; in situations where that
> > > is not the case, a separate mechanism could be used for that
> > > orthogonal parameter without breaking compatibility with
> > > existing parsers of language tags.
> >
> >This is all a discussion we on the IETF-languages list went through five
> >years ago, and in the intervening five years I think we have reached a
> >consensus on these issues, that consensus being reflected in the proposed
> >revision to RFC 3066. (Note that we made the relevant decisions over a
> >year and a half ago when we reached a consensus to register az-Latn etc.
> >The precedent was established then; the proposed revision adds nothing
> new
> >in this regard.)
> 
> Are we sure that this "others have reached a consensus without your
> objections, so we will not consider them" is a valid form of consensus?

I was merely trying to point out that the questions you are asking are not new, that decisions *have* been taken, and that the results are now part of the Internet legacy. You are certainly welcome to consider whether there's a better way and to propose some entirely new infrastructure for the Internet, but that should not prevent those of us who have been working on the evolution of the existing infrastructure for the past several years to continue to move forward in that evolution.

Or were you suggesting that at any time anybody should be able to question whether standards that have been in use for some time were formed with adequate consensus?

> > > Please see RFC 2026 sections 7.1, 7.1.1, 7.1.3, and 10.1...

> >7.1 says... The fact that not all are used, or that some are
> >used as they were specified in dated version of the ISO standard is not
> in
> >contradiction with 7.1 -- it's just one of "several ways in which an
> >external specification... may be adopted."
> 
> I am sorry but this does not stand. The proposed revision directly refers
> to ISO standards while there are Internet documentation of the way they
> should be used.
> 
> Examples/
> 1. OSI 3166 is refered to. RFC 1591 should. RFC 1591 introduces
> differences
> (we all live with) with OSI 3166 which is taken as a reference to know
> what
> is a country.
> 2. OSI 639 scripting fr-FR is used while RFC 1958 leads to fr-fr or FR-FR
> or FR-fr indifferently and calls for fra-fr to avoid confusion.
> 
> In RFC 1591and RFC 1958 parlance "en-GB" should therefore be "eng-uk"

RFC 1591 and RFC 1958 are specifications for completely separate protocols. Not only is it completely inappropriate to suggest that RFC 1766 or its successors must be subject to these unrelated specifications, to do so would break a large number of existing implementations of RFC 1766 and RFC 3066 (let alone the proposed revision). This is truly nonsense.

> >Thus, I see no difference between RFC 3066 and this proposed revision in
> >relation to compliance with the sections of RFC 2026 you referred to.
> 
> Full agreement. So there is no need for it - except to enhance the RFC
> 3066
> for its specific applications.  This is OK as long as this is clearly
> stated.

The goals for the proposed revision in enhancing RFC 3066 are clearly stated in the draft.

Peter Constable

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 30 Dec 2004 23:01:53 +0100

Full agreement. Thank you Tex.
This discussion now lead to nowhere and may delay the draft.

1. I have documented the needs and listed the discrepancies (only one asked 
a question on that, all the rest is noise over my comments on others 
positions - what is normal since the target was to comment a draft).

2. I have brought support to the current text with the necessary provision 
it is to replace RFC 3066 in the areas RFC 3066 was intended for in Jan 
2001 with possible extensions preferably subject to IAB guidance concerted 
with external liaison WG. Otherwise I oppose it.

3. I have received enough documented support from serious lurkers or list 
members to have a good understanding of what is needed and how it should be 
addressed. To come as an outsider helps catalyzing existing but dormant 
propositions.

4. I suppose serious initial opponents/surprised experts have now 
understood most of what I documented, and need time to digest if and how it 
could/should be amalgamated in, or separated from, RFC 3066 ter.

I have no vocation to be a martyr of any IETF cause and I will from now on 
only respond private and constructive mails on this issue.

I thank all those who contributed and apologize to those I may have 
confused or teased (but it was a tease-back :-). It was a very interesting 
exchange which shown the complexity to share network generations cultures 
and layers. I learned a lot. Among others that my current needs "which do 
not exist" will be helped by others.

If some are interested I have just started the 
http://mail.jefsey.com/mailman/listinfo/ml_jefsey.com mailing list. Its 
only purpose is to discuss (not disputing) the way the Internet Standard 
Process can be used to document a multilingual Internet. This means 
questions such as :

- what would a multilingual internet mean and what users needs would it address
- can the current IETF/IESG Internet standard process adequately document 
it, under which conditions
- what kind of architectural IAB guidance should be seek about a 
multilingual internet framework
- should a WG-Multilingual be investigated or not and if yes with which 
charter to propose
- what would be the impact of such a multilingual internet on the existing 
Internet documents and procedures and on NGN
- what kind of preparatory work/standard/best proactice, studies, contacts, 
etc. would be necessary
- how could this relate with other real world, users, standardization, 
intergovernance and WSIS entities.

I wish you all a nice 12/31 and an happy and fruitful multilingual new year!
jfc

At 22:02 30/12/2004, Tex Texin wrote:

>As the number of question marks, exclamation marks, asterisks and other forms
>of expressing digital shock and awe increase with each mail, I would like to
>suggest a temporary cease and desist policy with respect to responding to JFC
>until the chair chimes in, presumably after the holidays.
>
>The discussion doesn't seem to be headed towards consistent understanding of
>the policies and the discussion is no longer shedding much additional light.
>
>JFC's mails deserve a response, (of which there have been several) but now we
>are down a hole from which I do not see an end short of the chair clarifying
>definitively the policies and either rejecting or supporting the objections.
>
>The commentary doesn't seem to be affecting 3066bis at this point and probably
>won't unless the chair directs the authors to do something specifically...
>
>To the extent the discussion is taking time away from the finalizing of -09 or
>other issues, it is delaying something that  most have declared as needed 
>asap.
>To the extent it may be causing reviewers to tune out of 3066bis 
>discussion, it
>is also harmful.
>
>If there is are specific technical issues, they should continue to be
>discussed.
>
>My two cents.
>Wishing everyone a happy and productive 2005, whereever you are in 001 land.
>tex
>
>Ietf-languages mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/ietf-languages