Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Aug 2005 22:13:56 -0400

>  Date: 2005-08-28 20:33
>  From: "JFC (Jefsey) Morfin" <[email-masked]>

> The problem are:
[...]
> - the lack of alternative (are we sure there are no other 
> architectural way to address the same need without information leak)

I think the answer is "yes".  For tagging of content, there is no "leak",
only information -- that is the entire point of the tag.  For negotiation,
there necessarily has to be some exchange of information ("I prefer X").

> - the lack of encryption

See above re. the necessity of information exchange.  TLS is available to
protect against eavesdropping.

> - the "spam" aspect: I am imposed to receive the langtag.

You can of course ignore it if you wish.  I also fail to understand how
you can be opposed to a language tag as "spam" yet at the same time
apparently wish to compound the amount of "spam" by including icons,
dictionaries, timestamps, etc.  

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

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Aug 2005 22:29:12 -0400

>  Date: 2005-08-28 20:33
>  From: "C. M. Heard" <[email-masked]>

> However, RFC 2026 does not set the rules for
> non-standards track documents, as it explicitly says in Section
> 2.1.

Sorry, I don't see that anywhere in 2.1.  2.1 does say that non-standards
track specifications are not subject to the rules for standardization (as
in full Standard), but it goes on to point to the rules in 4.2 for
Informational and Experimental RFCs.

> There is a precedent, by the way: RFC 2341.  Note that it postdates
> RFC 2026.

Interesting.  Are there any others?  I have heard that an effort to publish
a particular obsolete specification as Historic received strong pushback,
with the recommendation for publication as Informational.

Aside from the label -- and that's not a clear benefit because Historic is
ambiguous -- I don't see much difference between Historic and an
Informational RFC with a suitable IESG note (a "warning label" if you will).

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 31 Aug 2005 05:42:54 +0200

Bruce Lilly wrote:

>> There is a precedent, by the way: RFC 2341.  Note that it
>> postdates RFC 2026.
 
> Interesting.  Are there any others?

Maybe 4156 (wais) & 4157 (prospero).  That's a bit special,
because it's a part of the effort to get rid of 1738.

> I have heard that an effort to publish a particular obsolete
> specification as Historic received strong pushback, with the
> recommendation for publication as Informational.

If you have son-of-1036 in mind, "strong pushback" isn't how
I recall Henry's info - it was more like "lacking enthusiasm".
I can't check it at the moment.
                               Bye, Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Aug 2005 11:31:51 +0200

Bruce Lilly wrote:
...
> Informational RFC with a suitable IESG note (a "warning label" if you will).

There's a difference. For example, imagine a media type called

   splat/illogical

that's been used for some years but is generally considered to be
illogically named, and a new media type has been defined to do the
same thing:

   splot/logical

It would then be reasonable to document splat/illogical as Historic
to explain its IANA registration, and to document splot/logical as
Informational.

But you're certainly correct that a health warning in the text of
the RFC is more important than a status marker in the index.

    Brian