Subject: [Ltru] Re: [psg.com #933] Java support

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:47:04 -0700

> Consequently, this item is marked "rejected"

I agree.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:50:44 -0700

> (1) whether to limit the repertoire that can be used
>      (a) to basic latin
>      (b) latin-1

I've changed my mind about this, and now support the ability to include
any Latin-script letter in the registry.

This topic always seems to lead to discussions about turning the
registry into a comprehensive reference of localized names of languages
and countries, so just in case it needs to be said, I reiterate my
objection to that.

>  (2) whether to "correct" data brought over from ISO, such as
>  the use of an incorrect character reference for glottal stop.

I remain convinced that the spacing acute accent in the official ISO 639
name "Gwich´in" is an error, but I won't pursue the matter further.
Frank is correct that if we start trying to "fix" these, it will be hard
to know when to stop.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:52:16 -0700

> Consequently, I've marked this one "rejected".

I agree.  The phrase "indicate the language" in the abstract has been
there since RFC 1766 with no apparent widespread confusion.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:53:22 -0700

> No one else had any problem with the phrase "information object",
> and no alternative proposal was agreed, so I've marked this item
> as "rejected".

I agree.  This term is intentionally general, and has been there since
RFC 1766.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:54:33 -0700

> No one else on the WG mailing list had a problem with the word,
> and no proposal for an alternative wording found support, so
> I've marked this item as "rejected".

I agree.  "Interchange" is a common data-processing word, and not
normally considered a source of confusion or ambiguity.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:56:08 -0700

> The question of whether the introduction to the registry draft
> should allude to its intended BCP status was raised in comment #9 in
> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html
>
> There was no support on the mailing list for this proposed change,
> so the proposal is marked "rejected".

No opinion.  This is a process question, best settled between the chairs
and editors.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:57:54 -0700

> Comment #10 in message
> requested an explanation of the difference between the words
> "tag" and "label".
>
>  No one else seems to have trouble with these words, and no
> replacement text was proposed, so I've marked this item "rejected".

I agree.  Neither the Introduction nor any other part of draft-00 or -01
"talks about labels" as stated.  The draft does refer to using tags to
"label" content, but that is hardly a confusing or inconsistent usage.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 21:59:48 -0700

> This question was issue number 11 in message
>  There was no support on the mailing list for a change, so
> this item is marked "rejected".

I agree.  The concept of a parser "recognizing" tokens is well-known,
and would never be interpreted as "authoritative" except by intentional
misreading.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 22:05:35 -0700

> This issue was raised in item 12 in
>  A mechanism describing how one determines whether a registry
> version is "current" needs to be spelled out.

The registry contains a date *as of which* it is current.

The only way to determine, just by looking at a registry version,
whether it is "current" or whether it has been superseded would be to go
back and mark it as such.  While it would be possible to do this for
files hosted by IANA (if non-current versions are made available there
at all), it would be quite impossible for locally downloaded versions,
which are implicitly encouraged in the last sentence of Section 6.

>  This is related to the charter requirement "For accessibility,
> it is to provide a mechanism for easily
> determining whether a particular subtag is valid as of a given date,
> without onerous reconstruction of the state of the underlying standard
> as of that time."

Since this requirement refers to validity "as of a given date," the
identification of each registry version by date seems sufficient.  As
stated above, it would be hard to imagine how anything beyond this could
even be accomplished.

>  This is also somewhat related to the charter requirement
> "It is expected to specify a mechanism for easily identifying the role
> of each subtag in the language tag, so that, for example, whenever a
> script code or country code is present in the tag it can be extracted,
> even without access to a current version of the registry."
> (This last phrase naturally leads one to ask the question, "how do I
> know whether what I have is current.")

It actually begs the question, since the whole premise is that you don't
*need* to know whether what you have is current in order to classify the
subtags.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 22:08:06 -0700

> Comment #13 in message
> requests clarification of the advice on the use of subtags
> in section 2.1.1 (of draft -00-)

No comment.  I've already expressed my objection to restrictions on the
recommended use of subtags.  The group's consensus was to recommend
certain restrictions, and in particular to implement Suppress-Script, so
I've accepted that and moved on.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 22:09:27 -0700

>  Comment #14 in message
>  requests that there should be language stating that the number
>  of subtags SHOULD be limited to four.

I oppose any such limit as unnecessary and arbitrary.  There is already
wording in the draft to deal with situations where an application must
truncate a tag due to space constraints.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 22:13:59 -0700

>  Comment #15 in message
>  asks whether an implementation that imposes length constraints
>  would still be considered conformant, and, if so, what constraints
>  would be permissible.

Actually, it does not ask that.  This comment is simply playing with
words, and should be rejected as frivolous.

Draft-00 says, "A conformant implementation need not support the storage
of tags which exceed a specified length."  Comment #15 asks about "an
application not supporting a NON specified length" (my emphasis).

Obviously the burden of specifying a maximum supported length is on the
application itself, and any application that truncates tags arbitrarily,
at a length known only to itself, violates the "clearly documented"
provision of Section 2.1.1.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 May 2005 22:15:36 -0700

> Comment #16 in message
>  suggests that "." should be used as a separater.
>
>  Subsequent discussion found no support for and much opposition to
>  this proposal.  A detailed response is in message
>  http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html

I agree.  Changing the hyphen separator to a dot or anything else would
break all compatibility with RFC 1766 and 3066, which would be a
critical violation of both the charter and common sense.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 11 May 2005 07:29:18 +0200

>normally considered a source of confusion or ambiguity.

1: a junction of highways on different levels that permits traffic to move 
from one to another without crossing traffic streams
2: mutual interaction; the activity of interchanging or reciprocating [syn: 
<http://dictionary.reference.com//search?q=reciprocation>reciprocation, 
<http://dictionary.reference.com//search?q=give-and-take>give-and-take]
3: reciprocal transfer of equivalent sums of money especially the 
currencies of different countries; "he earns his living from the 
interchange of currency" [syn: 
<http://dictionary.reference.com//search?q=exchange>exchange]
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 May 2005 13:17:12 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, May 10, 2005 9:56 PM
> Subject: [Ltru] Re: [psg.com #938] should introduction allude to intendedbcp status?
>

> No opinion.  This is a process question, best settled between the chairs
...

The last paragraph of section 2 of http://www.ietf.org/ietf/1id-guidelines.html
states:

| The Internet-Draft should neither state nor imply that it has any standards status;
| to do so conflicts with the role of the RFC Editor and the IESG. The title of the
| document should not imply a status. Avoid the use of the terms Standard, Proposed,
| Draft, Experimental, Historic, Required, Recommended, Elective, or Restricted in
| the title of the Internet-Draft. Indicating what status the document is aimed for
| is OK, but should be done with the words "Intended status: <status>".

With nroff, it would be easy to put "Intended status: BCP" among the items in the
upper left corner of the first page.  I don't know how to do it with xml2rfc.
I encourage the editors to include "Intended status: BCP" if they can do so
without expending too much time (more than five minutes) on figuring out how
to get the tools to do it.

The abstract already (-01) states "This document obsoletes RFC 3066 (which
replaced RFC 1766)."  That's the important part, which I believe satisfies
the heart of the comment.  Whether this ultimately becomes a BCP or not is
up to the IESG; we as a WG will only make a recommendation.

Randy, ltru co-chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 May 2005 13:49:00 -0700

Hi -

> Sent: Tuesday, May 10, 2005 10:08 PM
> Subject: [Ltru] Re: [psg.com #942] clarify advice on use of subtags
>

...

Ok, so I've marked this one "rejected", in the expectation that it can be
re-opened if we find problems in the text.

Randy, ltru co-chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 May 2005 17:25:48 -0700

Hi -

In light of the recent discussion, would it make sense to simply nail down
the maximum length of a tag, and require all conformant implementations to
support that length, thus eliminating the question of truncation?

Randy