Subject: [Ltru] Draft-4645bis-01 expires

From: "Doug Ewell" <[email-masked]>
Date: Thu, 19 Jul 2007 22:01:26 -0700

For those who are keeping track, draft-ietf-ltru-4645bis-01 expired on 
Wednesday, July 18 and will probably be removed from the RFC Editor site 
shortly.  We seem to be fairly close to resolving the UTF-8 question, 
but I'm still waiting for two other events -- a decision on extlangs vs. 
Macrolanguage field, and publication of the revised 639-3 data -- before 
preparing a new draft.  Hopefully these will both occur sooner rather 
than later.

In the meantime, if and when the current draft drops off the RFC Editor 
site, you can still retrieve copies from my site:

http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt
http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html

Zipped copies can be a nice thing to have when your draft is 916 pages 
long:

http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt.zip
http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html.zip

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: Addison Phillips <[email-masked]>
Date: Thu, 19 Jul 2007 22:35:49 -0700

It seems clear that the extlang argument will run past draft-07, whereas 
UTF-8 is currently in draft-07 with no opposition. Plus there are new 
things that 4645bis is supposed to tackle in draft-07. Perhaps it is 
time to prepare a new version---not for the data, but rather for the 
other text. After all, the heedless burning of integers needn't only 
apply to 4646bis.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: John Cowan <[email-masked]>
Date: Fri, 20 Jul 2007 02:00:14 -0400

Addison Phillips scripsit:

> It seems clear that the extlang argument will run past draft-07,
> whereas UTF-8 is currently in draft-07 with no opposition.

In what sense?  I continue to oppose it.

> Perhaps it is time to prepare a new version---not for the data, but
> rather for the other text. After all, the heedless burning of integers
> needn't only apply to 4646bis.

IIRC, Doug told us that generating a 4645bis draft is rather expensive
compared to a run of xml2rfc.

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan

---

From: Addison Phillips <[email-masked]>
Date: Thu, 19 Jul 2007 23:14:16 -0700

> In what sense?  I continue to oppose it.

I apologize for having missed that... although I don't recall your 
having said anything until now on the very most recent attempt to move 
to UTF-8---you've been vocal in the past.

This editor, please note, is growing annoyed with the on-and-off nature 
of the UTF-8 argument. I wish verily that the chairs would determine a 
consensus or lack thereof.

> compared to a run of xml2rfc.

Only if he regenerates the code table. I note that this isn't necessary 
this time around---the codes don't need any changing, but the 
instructions, etc., do need some work. Heck, I'd support publishing a 
version sans code list just to ensure that we're all in sync.

Note that I am not going to incorporate any macrolangauge/extlang 
changes in draft-07, no matter what. Having a draft-07/draft-02 baseline 
would be useful, in my opinion.

Addison

---

From: John Cowan <[email-masked]>
Date: Fri, 20 Jul 2007 02:31:14 -0400

> to UTF-8---you've been vocal in the past.

Fair enough.  Well, my process concerns are not yet assuaged, and won't
be until there is an end-to-end demo involving non-UTF-8 discussion
(using what convention?) and accurate (automated?) conversion
to UTF-8 either by IANA or someone on their behalf (whom? and how
transmitted?).

-- 
On the Semantic Web, it's too hard to prove     John Cowan    [email-masked]
you're not a dog.  --Bill de hOra               http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 Jul 2007 09:20:52 -0700

Hi -

As a co-chair...

> From: "Addison Phillips" <[email-masked]>
> To: "John Cowan" <[email-masked]>
> Cc: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Thursday, July 19, 2007 11:14 PM
> Subject: Re: [Ltru] Draft-4645bis-01 expires
...
> consensus or lack thereof.
...

Unfortunately, the technical discussion has thus far not worked through
all of the key points that need to be addressed before it makes sense
for us to declare a consensus.  Several decompositions of the issues
have been presented, but as I see it these are the related questions
that must *all* be answered before we can declare a consensus on this
bundle of issues called the "UTF-8 argument."

   1)  Are we willing to use a representation (for the discussion
       of changes on the [email-masked] list and communication
       with IANA) which is different (perhaps only mechanically/trivially so)
       from what is actually published in the registry files?

   2)  The registry file itself currently uses something which is similar
       to an NCR.  Are we willing to change the registry format to
          a) use actual NCRs for non-ASCII code points, making conversion
             to XML even more trivial than it already is, while still
             giving some fallback to folks inspecting the data for errors
             or looking at it through ASCII windows
          b) embed the actual (UTF-8 encoded) characters into the file
          c) something else?

   3)  Are we going to instruct IANA to maintain a "pure" ASCII version
       of the registry, in which everything not ASCII will have been flattened
       or translitered?

My sense of the discussion so far is that folks are OK with (1), and that
(3) won't have enough support to justify the cost.  The part that still needs
to be hashed out is the choice between (2a), (2b) and (2c).

So, please, let's wrap this up.  To me this means:

Determining what we need to say about (1) in 4646bis.
Making a choice from the various options in (2).
Agreeing that (3) is not our problem.

Randy

---

From: Peter Constable <[email-masked]>
Date: Fri, 20 Jul 2007 15:42:18 -0700

> From: Randy Presuhn [mailto:[email-masked]]

>        from what is actually published in the registry files?

I assume that those responsible for actually updating the records will be competent to do what's needed, so I am willing.

>           b) embed the actual (UTF-8 encoded) characters into the file

My vote: 2B

>        of the registry, in which everything not ASCII will have been

My vote: No.

Another possible issue (assuming consensus on a file with actual UTF-8-encoded characters): does the UTF-8 file begin with a UTF BOM/encoding signature?

Peter

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 20 Jul 2007 16:07:26 -0700

I agree with Peter #1-#3.

on the new question 4) does the UTF-8 file begin with a UTF BOM/encoding
signature?

I have a slight preference for adding the bomb, but fundamentally don't care
either way.

Mark

On 7/20/07, Peter Constable <[email-masked]> wrote:
> I assume that those responsible for actually updating the records will be
> competent to do what's needed, so I am willing.
>
>
> Another possible issue (assuming consensus on a file with actual
> UTF-8-encoded characters): does the UTF-8 file begin with a UTF BOM/encoding
> signature?
>
>
> Peter
>
>

-- 
Mark

---

From: David Conrad <[email-masked]>
Date: Fri, 20 Jul 2007 16:37:28 -0700

Folks,

I hesitate a bit to say this (not fully understanding what I'm  
getting myself into) but with respect to IANA, you should focus on  
the future and what is the best technical approach for the registry.   
ICANN is working to increase/improve its "internationalization" and  
part of the XML-ization of IANA registries is to give us the freedom  
to do more than ASCII fixed column width text tables.  As long as the  
registry maintenance can be automated such that non-technical IANA  
staff can do what needs to be done, we'll not raise any objection.

Rgds,
-drc

P.S. If somebody wants to help and provide code, we'd be more than  
happy to accept... :-)

---

From: Martin Duerst <[email-masked]>
Date: Sat, 21 Jul 2007 09:57:40 +0900

I agree with Peter (and Mark) on the issues below.
I have a strong preference against a BOM.

Separately from our work on the drafts, we should continue
(as Randy already has done) to lobby the IETF into updating
their mailing list/archiving software so that UTF-8 (as well
as any other character encoding) is shown correctly.

Regards,   Martin.

At 07:42 07/07/21, Peter Constable wrote:
>UTF-8-encoded characters): does the UTF-8 file begin with a UTF 
>BOM/encoding signature?
>
>
>Peter
>
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 Jul 2007 23:14:35 -0700

Hi -

As a co-chair...

> From: "David Conrad" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Friday, July 20, 2007 4:37 PM

There's been quite a bit of discussion of whether to go to an XML
format for the registry, with a *slight* preference for making the
change, but not what I'd be willing to even call a "rough consensus."
I'd characterize the previous discussion as somewhat inconclusive,
since neither side really seems to have pursued the arguments to
their logical end.

I do think this is a good time to try to get closure on this question,
since it does overlap somewhat with the UTF-8-related questions.

The default position for the moment would be to stick with the
customized record-jar, modified to permit inclusion of UTF-8
rather than NCR-like stuff.  If we don't have a major groundswell
of support for XML, include contributions of suggested schemas,
then the decision of whether and how to provide XML support for
the language subtage registry would be left to IANA's imagination.

As a technical contributor, my personal preference would be to go
to XML, using NCRs for all non-ASCII bits.  I think that would make
things easiest for IANA, ASCII-limited folks, and simplify email
exchanges of information, while still making visual checking
trivial.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Sat, 21 Jul 2007 19:32:52 +0900

As a co-chair, I share Randy's assessment of the situation.

As a technical contributor, my personal preferences are rather
opposite: I prefer going to UTF-8, without going to XML.

I prefer going to UTF-8 despite me not having an email client
that can handle full UTF-8, because at this day and age, and
(as Chris Newman has pointed out) even more in the future,
email clients (or other software) not being able to handle
will get even rarer than they already are. I also think that
while strictly speaking, UTF-8 is a backwards incompatible
change, most actual implementations either won't have problems
accepting UTF-8 or can easily be changed to accept it.

Switching to XML, on the other hand, would require more major
changes in implementations. It would also require some extended
discussions over details of the XML structure, which might
easily delay our work further.

Regards,    Martin.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 21 Jul 2007 05:42:39 -0500

On Fri, Jul 20, 2007 at 11:14:35PM -0700,
 Randy Presuhn <[email-masked]> wrote 
 a message of 53 lines which said:

> If we don't have a major groundswell of support for XML, include
> contributions of suggested schemas,

There are two, one in RelaxNG and one in DTD. See
http://www.langtag.net/registries.html Discussions on these schemas
are welcome (but I agree with Martin Dürst, even if we decide to go
XML, the discussion on the schemas will take long)

PS: if some people from LTRU are in Chicago this week, this may be a
good opportunity for a beer and informal-BOF meeting.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 21 Jul 2007 06:10:17 -0500

On Fri, Jul 20, 2007 at 03:42:18PM -0700,
 Peter Constable <[email-masked]> wrote 

> UTF-8-encoded characters): does the UTF-8 file begin with a UTF

This one is easy: NO

RFC 3629, section 6 :

  o  A protocol SHOULD forbid use of U+FEFF as a signature for those
      textual protocol elements that the protocol mandates to be always
      UTF-8, the signature function being totally useless in those
      cases.

---

From: Addison Phillips <[email-masked]>
Date: Sat, 21 Jul 2007 09:16:52 -0700

Um... that's for protocols, not text files.

I don't personally think we should include a BOM, but one would not be 
misplaced in this context.

Sadly, I haven't had time to renew draft-phillips-record-jar in awhile, 
let alone finish it up. Sadly because if I had finished it we could just 
use it as a reference, saving ourselves a good bit of text.

That document talks about character encodings and requires the encoding 
to be declared at the front of the file:

%%encoding:UTF-8

It would probably be a good idea to put an encoding signature like that 
in the file, since not everyone reads the RFC before looking into the 
registry. Such an obvious textual hint would help users adjust their 
browsers or text editors to view the file correctly.

Addison