Subject: AD nits

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 10:24:26 -0600

Alexey and I have been working on a set of "AD nits" that come up again
and again during our IESG reviews of various Internet-Drafts. We'd
welcome feedback from folks in the Applications Area. You can find the
list here:

http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 03 Jun 2010 15:02:17 -0400

> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues

interesting and good idea. no comment/info on the 
stringprep/nameprep/newprep needs for protocol identifiers? ie. should I 
care about this and if yes, what should I do.

Marc.

> Thanks!
>
> Peter
>
>
>
>
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Jun 2010 16:54:00 -0400

> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues

In "Dates and Times", we should probably say more about time zones,
particularly time-zone names.  vCards have an issue with how to name
time zones, which prompted this now-expired draft:
https://datatracker.ietf.org/doc/draft-leiba-tzregistry/

More recently, Cyrus had tried to kick something off, which is why I
abandoned the tzregistry draft, but I can't find a reference to it.

Barry

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Jun 2010 08:59:25 +0800

HTTP:  BCP 56 contains some good advice, some dangerous advice.  Adequate warning signs for the uninitiated might help.

I know that Lisa had some updated advice on the use of HTTP.  Maybe you can get your hands on that and share it.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Friday, 4 June 2010 2:24 AM
> To: [email-masked]
> Subject: AD nits
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Jun 2010 21:31:32 -0400

--On Thursday, June 03, 2010 10:24 -0600 Peter Saint-Andre
<[email-masked]> wrote:

> Alexey and I have been working on a set of "AD nits" that come
> up again and again during our IESG reviews of various
> Internet-Drafts. We'd welcome feedback from folks in the
> Applications Area. You can find the list here:
> 

Peter,

Nice start and a worthwhile effort.

General observation:  This document is a mixture of "issues we
have found in reviewing documents" and "protocol design
considerations".  The latter overlap with other work (not
necessarily a bad thing) but are issues that WGs should be
dealing with lots earlier than submitting documents for review.
If they aren't spotted and dealt with until the review process,
someone or something is in big trouble, IMO.

More specific observations:

(1) The i18n stuff is pretty weak, IMO.  I think that many of us
have come to the conclusion that RFC 2277 (BCP 18) is badly
outdated (not wrong, just inadequate) and that "use UTF-8" is
not an adequate story.  That is a lot of the reason RFC 5198 was
done. It should be seen as a "be sure you are clear about this
in designs and documents" spec rather than a "do this" one, but
the issues are no less important.   "Unicode normalization",
which you have put into a separate subtopic, is really just one
of those 5198 issues that 2277 does not address.    Another
important one is how Unicode is profiled wrt the characters that
are acceptable for use in a given protocol: "use Unicode" is
rarely a satisfactory answer, normalization doesn't cover all of
the issues, and a decision to permit, e.g., symbols,
line-drawing and other rendering characters, etc., is actually a
pretty big deal.  It gets to be an especially big deal if one
starts including mechanisms for character input (whether a
character can be typed given a given keyboard and input method
mechanism) and so on... and protocol designers should probably
be considering those issues.

(2) I don't know quite what a "binary password" is, but, if that
is actually what you mean, it doesn't belong under
"Internationalization".  On the other hand, if one is going to
do localization of any sort, specifications should be clear
about how one identifies locales and how one gets from one
locale to another.

(3) As a substantive point, RFC 2482 notwithstanding, recent
versions of Unicode have very strongly discouraged the use of
language tags.  See TUS 5.x, Section 16.9.  While TUS 5.0
identifies this section simply as "Tag Characters", it worth
nothing that 5.2 goes so far as to rename it as "Deprecated Tag
Characters" and the text has changed from "strongly discouraged"
(in 5.0) to "deprecated, and should not be used" in 5.2.  See
http://www.unicode.org/versions/Unicode5.2.0/ch16.pdf for the
latter.   The conventional wisdom today (reinforced by the
referenced sections of The Unicode Standard and other work) is
that, if language/script tagging is needed embedded in text
(i.e., not via out of band mechanisms like language or charset
tagging in headers), the application should probably be using
XML or some other markup context.   I note that 2482 justifies
itself largely on the basis of the needs of ACAP.  ACAP is
(sadly IMO) nearly dead these days; if we were to create a new
protocol with the same functionality, I assume it would use some
sort of XML schema which could, in turn, identify script or
language elements as needed. 

Our experience of the last decade or so is that most, or all,
protocols that "didn't have language tags originally" need
rather careful rethinking, not some handwaving involving a story
like "UTF-8 is just a superset of ASCII and we can use language
tagging".  Note, too, the TUS discussion about how infrequently
language tagging is actually needed in Section 5.10 (see
http://www.unicode.org/versions/Unicode5.2.0/ch05.pdf).  While
reasonable people might disagree with the conclusions there, one
should at least carefully consider it.

In any event, I suggest that it may be time to consult the
authors and then move 2482 to Historic.  In no event is it wise
for you to be recommending it.

(4) I suggest also that RFC 5646 is inappropriate as a citation
without a profile about how it is to be used and what is to be
specified.  Without that, its many elements and terms are a
recipe for interoperability failures.  

(5) The MIME "content-language" header might be worth mentioning
as another way to supply whole-document language tagging.

(6) Given our fairly disastrous experience with the famous
"MIME-Version: 1.0" and, more controversially, some issues with
evolution of HTTP, the "Versioning" section may need some
expansion.  Statements equivalent to "Protocol versions happen,
so it's usually important to define a version field of some
kind" are exactly what got us into the MIME-version mess.
Design of any extension model requires an lot of analysis and
effort to get right, not just assignment of a few numbers.  I
know that you know that and the material in RFC 3920 appears to
reflect just that sort of analysis, but the current statement in
the draft and suggestions about reuse of 3920 text seem to
encourage underestimating the complexities of working out a
versioning design in favor of saying something that might get
past AD review.

best,
    john

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 3 Jun 2010 21:10:16 -0700

Hi -

> From: "John C Klensin" <[email-masked]>
> To: "Peter Saint-Andre" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 03, 2010 6:31 PM
> Subject: Re: AD nits
...
> (in 5.0) to "deprecated, and should not be used" in 5.2.
...

I know you know better than to confuse "language tags"
(BCP 47) with the (rightly) deprecated "tag characters"
from Unicode.

Randy

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jun 2010 00:47:18 -0400

--On Thursday, June 03, 2010 21:10 -0700 Randy Presuhn
<[email-masked]> wrote:

>> To: "Peter Saint-Andre" <[email-masked]>;
>> <[email-masked]> Sent: Thursday, June 03, 2010 6:31 PM
>> Subject: Re: AD nits
> ...
>> nothing that 5.2 goes so far as to rename it as "Deprecated
>> Tag Characters" and the text has changed from "strongly
>> discouraged" (in 5.0) to "deprecated, and should not be used"
>> in 5.2.
> ...
> 

Of course.  That said, it has been a long week, it is hot,
anything could happen, and the terms "language tagging" and
"language tag identification character" appear in both TUS
Section 16.9 and RFC 2482. From a terminology standpoint, the
fact that one implements "language tagging" by using a "language
identification character" followed by a "language tag" spelled
out in "special-use tag characters" whose only permitted
"special" use is for writing "language tags" is, at best, a trap
for the unwary.

The Unicode "tag characters" explicitly include language tagging
and are the subject of RFC 2482.  The nits draft recommends
using RFC 2482 "tag characters" to identify languages, which is
part of what I was commenting on and suggesting be removed.  

The language tags and "tag characters" are nonetheless tied
together.  Both 2482 and TUS Section 16.9 point to BCP 47 (RFC
5646 and 4647; formerly 4646 (referenced in TUS 5.0 Section
16.9), RFC 3066, and RFC 1766 (referenced from 2482 itself)).
Put differently, one thing (really the only thing) one could do
with the [deprecated] tag characters is to invoke language
tagging strings as specified in BCP 47.

So I don't think I'm confused at all.

I do believe that any protocol that uses BCP 47 language tags
(presumably independently of anything having to do with those
Unicode in-line "tag characters", which we agree were a bad
idea) should be explicit about the level of detail expected in
those tags when they are used.  If that is not done and there
are wide variations in how much detail is specified, the
protocol needs to establish matching rules (possibly by explicit
invocation of RFC 4647) as to how the relationships are to be
handled.  Whether such a protocol specifies level of detail or
matching rules (via 4647 or otherwise), its doing so explicitly
is what I was referring to when I made the comment about a
profile of RFC 5646.  

We might disagree about that "profile" conclusion, in which case
we may need to have a separate discussion sometime, but I don't
think I'm confused on that subject either.  

If you think I'm confused about any of that, please explain.

If anyone else finds the discussion above confusing, I'm sure
that the Unicode Consortium would welcome constructive
suggestions about how to improve the terminology.

best,
   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 04 Jun 2010 15:25:40 +0900

Regarding time zones, you may also want to consult or point to
http://www.w3.org/TR/2005/NOTE-timezone-20051013/.

Regards,    Martin.

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 04 Jun 2010 15:25:40 +0900

Regards,    Martin.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 03 Jun 2010 12:24:09 -0500

> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues

Peter: Looks good.  A couple of quick comments.

1) You may want to refer to Narten and Alvestrand [1] on
  writing IANA consideration section in RFCs.  The MIME/Media
  Types section can probably be titled "IANA" or something
  along those lines.

2) You may want to refer to Rescorla and Korver [2] on
  writing security consideration section in RFCs.

[1] T. Narten and H. Alvestrand, "Guidelines for Writing an
  IANA Considerations Section in RFCs," RFC5226 (also BCP0026).
[2] E. Rescorla and B. Korver, "Guidelines for Writing RFC Text
  on Security Considerations," RFC3552 (also BCP0072).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 4 Jun 2010 14:27:56 -0700

Hi -

I think the problem at hand is simpler than all that.

Something constructed using the deprecated Unicode
"language tagging characters" couldn't possibly be
a language tag.  The grammar of language tags
(RFC 5646 pages 5-6) makes it quite impossible.
They were simply designed to be easily mappable into
language tags.

The deprecated "language tagging characters" were
an idea whose time never came, and should be forgotten ASAP, IMO.
To that extent, I agree that if RFC 2482 is to be referened at all,
it should be in the form of a "don't do that".

FWIW, what would it take to declare 2482 "Historic"?

Randy

----- Original Message ----- 
> From: "John C Klensin" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 03, 2010 9:47 PM
> Subject: Re: AD nits
>
> 
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jun 2010 20:17:57 -0400

Randy,

To avoid complicating the discussion unnecessarily:

(1) the "nits" draft had not explicitly recommended the
possibility of using 2482, I would not have raised these issues
at all and probably wouldn't have noticed them.  2482 slipped
off my radar long ago, probably about the time it was written.

(2) If the "nits" draft is changed to either say "don't even
think about using that" about 2482 or even to drop all mention
of it, I think we are back to where we should be.

(3) At least in recent years, getting a document moved to
historic usually requires that someone generate an I-D that says
"move X to historic" and, ideally, explains why.  I think "an
idea whose time never came, and should be forgotten ASAP" would
about cover the explanation.  I think it would be courteous and
appropriate to ask Ken and Glenn if they have inputs or
objections but then it ought to be easy to generate the I-D and,
the AD's willing, push it through the system.  I'd be willing to
do a little work to generate the I-D if that would help.  It
isn't as if those tagging characters have a huge installed base
:-(

    john

--On Friday, June 04, 2010 14:27 -0700 Randy Presuhn
<[email-masked]> wrote:

> an idea whose time never came, and should be forgotten ASAP,
> IMO. To that extent, I agree that if RFC 2482 is to be
> referened at all, it should be in the form of a "don't do
> that".
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Jun 2010 18:41:38 +0900

Hello John,

On 2010/06/05 9:17, John C Klensin wrote:
> the AD's willing, push it through the system.

I have added the two gentlemen to the cc list.

In my recollection, http://tools.ietf.org/html/rfc2482 and the scheme it 
describes was only invented to prevent even worse, in particular the 
proposal in http://tools.ietf.org/html/draft-ietf-acap-mlsf-01, which 
messed around with UTF-8 in a very uncomfortable way. (I was also 
involved in a counterproposal, please see 
http://tools.ietf.org/html/draft-ietf-acap-langtag-00.)

Given this background, and the fact that Unicode itself has depreciated 
the "language tag characters", I have no doubts that the two gentlemen 
will be very glad to help obsolete RFC 2482. But I'll let them speak for 
themselves.

> I'd be willing to

It isn't, and I'm glad it isn't. However, some conversion libraries (in 
particular libiconv) go to the trouble to remove these (rather than just 
throw a "not convertable" error) when converting to encodings that only 
cover a subset of Unicode (e.g. iso-8859-1,...). So some of this stuff 
might actually float around out there :-(.

Regards,    Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Jun 2010 10:19:13 +0100

Marc Blanchet wrote:
> stringprep/nameprep/newprep needs for protocol identifiers? ie. should 
> I care about this and if yes, what should I do.
I don't think we have a good answer to this in Apps. Once we do, this 
should definitely be added.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Jun 2010 10:24:46 +0100

> http://www.w3.org/TR/2005/NOTE-timezone-20051013/.
Personally I don't like to block documents in IESG review on something 
that has no IETF consensus (or even  the Apps area wide agreement on the 
best solution).