Subject: [Ltru] items addressed by current editor's draft

From: "Addison Phillips" <[email-masked]>
Date: Thu, 2 Jun 2005 11:04:50 -0700

Dear Randy,

I show the following open items addressed by the current editor's draft, pending the co-editor's declaration of consensus on them:

#944: length restriction handling is now spelled out in depth.
#954: aliases are all supported. Mapping behavior is now defined.
#998: grandfathered items become deprecated if new registrations replace them.
#1000: There is a 'Suppress-Script' field.
#1016: Extlangs are restricted to 3 (not 5) based on #944
#1017: Changed 'Recommended-Prefix' to 'Prefix' and made it normative
#1018: Did not add 'Macrolanguage', although it is indistinguishable from #1017 in fact.

#1019: unresolved. I voted against it.
#1020: resolved by #954's resolution. Entries are stable and vald forever. Mappings ('Preferred-Value' fields) show the replacement values.
#874: resolved by solution to #954 also: parent organization changes are propagated as long as they don't conflict with the rules of the registry (which includes handling when they do).
#895: the Date A/Date B fix took care of this some time ago.
#893: ensured that the text spelled out that File-Date indicates the relative currency of shadowed registry versions.

Not addressed:

#892: why is this still open? The registry is a text file. The likelihood of it getting too large is very small. I thought this was disposed of.
#968: the load on IANA servers will not be appreciably higher and no implementation should rely on the on-line version of the registry to prevent DoS attacks. Please reject.

Unless there are other items hiding out and provided there is consensus on the above changes, this should close everything that is open. What issues remain before we can start looking at a last call?

Addison

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com

Chair, W3C Internationalization Core Working Group
http://www.w3.org/International

Internationalization is not a feature.
It is an architecture. 

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Jun 2005 23:28:37 +0200

Addison Phillips wrote:

> What issues remain before we can start looking at a last
> call?

#1019 "redundant tags to appendix" is the last ?  Then let's
please forget it, nobody supported it, you didn't like it,
it's really not important => editor's choice.  Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Jun 2005 23:01:07 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, June 02, 2005 11:04 AM
> Subject: [Ltru] items addressed by current editor's draft
>

> Dear Randy,
>
> I show the following open items addressed by the current editor's draft,
> pending the co-editor's declaration of consensus on them:

(I assume you meant co-chair rather than co-editor :-)

> #944: length restriction handling is now spelled out in depth.

I've left this one open, since this discussion continues in the
perverse tag thread.

> #1000: There is a 'Suppress-Script' field.

These three are all marked "resolved".

> #1016: Extlangs are restricted to 3 (not 5) based on #944

I've left this one open, since this discussion continues in the
perverse tag thread.

> #1020: resolved by #954's resolution. Entries are stable and vald forever.
> Mappings ('Preferred-Value' fields) show the replacement values.
> #874: resolved by solution to #954 also: parent organization changes are
> propagated as long as they don't conflict with the rules of the registry
> (which includes handling when they do).

Ok, these are all closed.

> #893: ensured that the text spelled out that File-Date indicates the
> relative currency of shadowed registry versions.

That's not the core issue in #893.  It's still open, but I *think* a
brief discussion will be sufficient to reach closure.

> Not addressed:
>
> #892: why is this still open? The registry is a text file. The likelihood
> of it getting too large is very small. I thought this was disposed of.

There have been no followups on this issue.  I'd like some discussion
(with the issue number in the subject line PLEASE).

> #968: the load on IANA servers will not be appreciably higher and no
> implementation should rely on the on-line version of the registry to
> prevent DoS attacks. Please reject.

As a technical contributor, I'm not totally happy with the language
in the -03 draft addressing this issue; I'll post a followup in that
issue's thread.

> Unless there are other items hiding out and provided there is consensus
> on the above changes, this should close everything that is open. What
> issues remain before we can start looking at a last call?
...

I urge everyone to review the mailing list discussion for any issues
that should be recorded in the issue tracker, and to verify that they
can live with the solutions proposed in the i-d.

Let's try to wrap up the discussions by the end of this week.
When the new i-d appears, we should be able to do our WG last call
on it.

Randy, ltru co-chair

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 01:04:43 +0200

> (I assume you meant co-chair rather than co-editor :-)

No, it's really co-editor, Chairs can't manipulate submitted
drafts.  Only co-editors can, in theory.  It took me weeks
to find out who tried to manipulate a submitted SPF draft -
it was apparently the AD, not the co-editor.

>> #1016: Extlangs are restricted to 3 (not 5) based on #944

That's fine, Peter said "go", it also works with 33 and 2047.
 
> There have been no followups on this issue.  I'd like some

At the moment it's below 80 KB.  Adding 7000 * 80 characters
would push it to about 640 KB.  Not nice, but also no reason
to invent new IANA tricks.
                           Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Jun 2005 20:34:11 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, June 07, 2005 4:04 PM
> Subject: [Ltru] #892 640 KB (was: items addressed by current editor's draft)
>

...

???

Declaring consensus is the job of a (co-)chair, not a (co-)editor,
if there is any question about whether there is a consensus.  See
RFC 2418 section 3.3, for example.

Submitted internet drafts aren't supposed to change, other than
to go away when expired or superceded.  This is the first time I've
heard of one being modified after posting.  (I did see a couple
mangled during posting by the secretariat's email software a while
ago.)

During the RFC-editing process, page layout changes happen as a
matter of course, and IESG notes might be added, but the AUTH48
stage serves as a check on anything getting broken.  If there is
substantial IESG or IETF last call feedback, then normally a new i-d
would be posted.  No one likes to see significant changes in AUTH48,
since they provide a potential source of errors and process end-runs.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 11:44:01 +0200

> Declaring consensus is the job of a (co-)chair, not a

Yes, and you also appoint editors, and pick drafts as official
WG drafts (at least for the -00 version), and maybe it's also
your job to tickle the AD if something's ready for "last call".

But you don't _edit_ - only the editors edit (later with the
help of the RfC editor).  The IESG can add notes.  AFAIK you
can't add notes or edit.  Maybe you could appoint yourself as
editor, but that's an odd idea, it would skip a complete step
in the checks ad balances.

> This is the first time I've heard of one being modified
> after posting.

In their "48 hours" the authors can still fix typos.  And the
RfC editor probably tries to catch formal problems, otherwise
they'd simply attach numbers and publish after approval, and
there would be almost no queue delay, let alone four months.

> No one likes to see significant changes in AUTH48, since they
> provide a potential source of errors and process end-runs.

In the case where I tried to find out what happened it was a
note to the RfC editor to remove a critical "NOT RECOMMENDED".
Now it's a complete chapter.  And of course "NOT RECOMMENDED".

                              Bye, Frank