Subject: RE: [Ltru] 2nd WG last call: Abstract

From: "Addison Phillips" <[email-masked]>
Date: Wed, 17 May 2006 07:02:55 -0700

I agree with Doug. I think the best way to address the problem is to change it from its current:

--
Filtering produces a potentially empty set of language tags...
--

To a "less negative":

--
Filtering produces a (potentially empty) set of language tags...
---

I'm going to make this change, run idnits and the other tools, and submit draft-13 this morning.

Best Regards,

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Doug Ewell [mailto:[email-masked]]
> Sent: 2006年5月17日 6:47
> To: Debbie Garside; 'Addison Phillips'
> Subject: Re: [Ltru] 2nd WG last call: Abstract
> 
> Hi Debbie,
> 
> > I can see where you programmers are coming from but if you look at the
> > filtering description within the abstract as it stands:
> >
> >> Filtering produces a potentially empty list
> >>    of language tags
> >
> > It rather focuses on the negative.  Perhaps it would be better to say:
> >
> > "Filtering produces a set of language tags."
> >
> > In database query terms one would expect that if there is no match the
> > list would be empty.
> 
> I agree about not wanting to focusing on the negative, but I also feel
> it needs to state somewhere that this set can have zero elements --
> especially for the non-programmers who might not think of this case.
> 
> Addison, can you think of a way to spin this wording?
> 
> --
> Doug Ewell
> Fullerton, California, USA
> http://users.adelphia.net/~dewell/
> 

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

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 17 May 2006 07:17:47 -0700

I think the parentheses shift the emphasis away from the negative 
adequately.  Hopefully this will suit Debbie's need also.

Is this going to be a final submission for IANA Last Call, or are we 
going to go through the same drill all over again?  (Issue draft, wait 
for LC to be called, let two weeks pass, flood of comments, repeat...)

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "'Doug Ewell'" <[email-masked]>; "'Debbie Garside'" 
<[email-masked]>
Cc: "'LTRU Working Group'" <[email-masked]>
Sent: Wednesday, May 17, 2006 7:02
Subject: RE: [Ltru] 2nd WG last call: Abstract

I agree with Doug. I think the best way to address the problem is to 
change it from its current:

To a "less negative":

I'm going to make this change, run idnits and the other tools, and 
submit draft-13 this morning.

Best Regards,

Addison

Addison Phillips

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 17 May 2006 07:22:46 -0700

Martin has indicated that this will be submitted to our AD, rather than going back to another WG last call.

Addison

Addison Phillips

> Sent: 2006年5月17日 7:18
> To: Addison Phillips; 'Debbie Garside'
> Cc: 'LTRU Working Group'

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 17 May 2006 07:47:20 -0700

Outstanding.

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "'Doug Ewell'" <[email-masked]>; "'Debbie Garside'" 
<[email-masked]>
Cc: "'LTRU Working Group'" <[email-masked]>
Sent: Wednesday, May 17, 2006 7:22
Subject: RE: [Ltru] 2nd WG last call: Abstract

Martin has indicated that this will be submitted to our AD, rather than 
going back to another WG last call.

Addison

Addison Phillips

---

From: Martin Duerst <[email-masked]>
Date: Fri, 19 May 2006 06:38:24 +0900

[co-chair hat on]

 >going back to another WG last call.

Yes indeed.

 >> for LC to be called, let two weeks pass, flood of comments, repeat...)

The first WG Last Call brought up quite a few substantive issues, and
resulted in significant changes in the document. It was therefore
necessary to make another WG Last Call. The second WG Last only brought
up editorial issues, which means we can move forward with the document.

This is my assessment as the 'managing' co-chair for the matching
document. If anybody disagrees, they should say so soon, and why.

Here are the next steps:

- Editors, please officially submit another draft version of the
   matching document. With this, everybody can use an official version
   to cross-check that their Last Call comments have been addressed.
   Also, I will use this version to prepare the necessary documents
   for submission to the Area Director in charge and to the IESG.

- I plan to do my side of the work over the weekend, but we probably
   have to give everybody a couple days after the draft officially
   appeared for cross-checking.

- If there are any further problems found, the editors will have to
   roll further drafts. But if not, this will be the draft that goes
   to the IESG.  "Further problems" at this stage can be mainly two
   things: 1) If find something that doesn't conform to one of the various
   checklists that the IETF has for this stage (I don't expect anything
   serious, because our editors have been aware of this all the time.)
   2) Somebody finds that the editors didn't understand, or made a
   mistake when implementing, their (2nd!) Last Call comments.
   Any other comments or changes are in principle out of range at this
   stage, although we will still fix obvious typos and we in principle
   would still be open (as we are at any stage) to going back to fix
   serious substantial errors if there were any.

Regards,    Martin.

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 18 May 2006 14:56:46 -0700

Thank you, Martin.

>    for submission to the Area Director in charge and to the IESG.

Draft-13 was submitted this morning (Pacific Time) and, with any luck, will
be published shortly. Unofficial copies (which are identical to the
submitted document) are posted on my personal website:

http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.txt
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.html
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.xml

I did not generate a static diff. There is a TinyURL link on my home page
that causes rfcdiff to generate one for you, should you desire it.

Note that I ran idnits. The only warning was that we were missing the RFC
2119 text (we aren't: xml2rfc generates the text with a pair of very small
differences that confuse the tool---the word "keywords" is used instead of
"key words" and the reference to RFC 2119 is in square brackets in our
version (since it is a reference)).

I hope you don't find anything in your review, but am prepared to make any
last second changes that result from it or from the reviews of others.

For the editors,

Addison

Addison Phillips

> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2006?5?18? 14:38
> To: 'LTRU Working Group'; Addison Phillips; Mark Davis
> Subject: Next Steps
> 
> [co-chair hat on]
>