639-6.
The argument against the RFC 3066bis effort on the basis of the asserted
existence of "20,000 languages" is attributable to M. Morfin alone. He
is not being truthful in saying that he does not oppose the draft; he
has spent the entire lifetime of the LTRU WG, and before, shouting his
oppo
tandard.
> I have documented enough (too much :-)) during these last days that I
> support (one can read my mails of end of December 2004) the Draft
> with the provision it is not exclusive and serves the Internet
> community rather than exclude its R&D and innovation capacity.
have been:
"variant" subtags and "grandfathered" tags
There is no such thing in the draft as a grandfathered subtag.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
together for a specific
purpose (as for a chartered tour)."
Exercise for the reader: Explain why this is a bad thing for an IETF
Working Group.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
JFC (Jefsey) Morfin wrote:
> From the input of Doug Ewell its _initial_ version withISO 639-6 will
> include 40.000 lines.
I never said that. I would not make any statement about ISO 639-6 when
the data is not available.
I said that the deltas for the initial version with ISO 639-*3* wou
tandards it
uses must themselves be IPR-protected.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ls have a technical basis, rather than being
ad-hominem.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
TF, as we have heard, is by individuals, not by representatives
or delegates or spokesmen.
Let's focus on the drafts, and have a productive discussion.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
e co-chairs and group thought best. There would be no need for a
separate initialization document otherwise.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
rectible errors or omissions they may
introduce, and live with the uncorrectable errors? Just wondering.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
quot; to
"uncorrectable" but left "correctible" uncorrected.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
TRU is ever revised to incorporate
subtags based on ISO 639-3 codes, the additional registry information
would occupy 740 pages, and suggested that this amount of material might
be inappropriate to publish as an RFC or even an I-D.
A 118-page draft consisting almost entirely of a code li
name: aroumain; macédo-roumain
> Indigenous name: armâneashti
In accordance with section 2, item 2 of draft-ietf-ltru-initial-04, this
needs to be added to the initial registry.
Håvard has already been asked about the duplication of
"Macedo-Romanian."
--
Doug Ewell
Fullerton, Californ
Hallam-Baker, Phillip wrote:
> If you allow a bunch of engineers to create their ideal working
> conditions they would allow unlimited scope for technical excellence
> with no hard deadlines and no need to ever interact with the actual
> customers.
Well said.
--
Doug Ewe
lerated in any face-to-face working environment.
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
uss.
It has already been explained here that this has NOTHING to do with
tolerance for different opinions. It has everything to do with the
obnoxious, abusive, disrespectful manner in which those opinions have
been expressed.
--
Doug Ewell
Fullerton, California
http://users.adelphia
ind.
(I do disagree with Jefsey's opinions, but I also disagree with a lot of
other people who treat me with more respect and less contempt, and
consequently I have no problem with them.)
I really don't want to drag this on. You and I have a difference of
opinion about how this P
> shut up or get back on the subject at hand, and the IETF can get back
> to it's business of documenting and improving the 'net.
For some reason this reminds me of "O: The Oprah Magazine."
--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
___
Joel Jaeggli wrote:
The detailed schedule is now available. It is still subject to change.
Streaming Begins at 0800 PST (UTC/GMT -7) Monday November 7th.
Nit: PST is UTC+8, not UTC+7.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell
m. I remember unisys
and the gif debacle, among others.
Thus proving Anthony's point. The GIF debacle had nothing to do with
Microsoft.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Iet
I burbled:
The detailed schedule is now available. It is still subject to
change. Streaming Begins at 0800 PST (UTC/GMT -7) Monday November
7th.
Nit: PST is UTC+8, not UTC+7.
Of course this should have been:
Nit: PST is UTC-8, not UTC-7.
--
Doug Ewell
Fullerton, California, USA
http
Stephane Bortzmeyer wrote:
If everyone were
Voltaire, we would not need smileys to express irony.
That is awesome. That is going straight into my fortune-cookie file.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell
draft-ietf-ltru-initial-06.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
pages, constituting the initial contents of the RFC 3066bis registry,
will be removed from the document before publication.
But thanks for the heads-up. I'll be careful to watch for any
unanticipated changes.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.n
ble software will be
able to do the same in the future.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Perhaps it's just me, but I find it bizarre that the question of
limiting RFC text to ASCII vs. UTF-8 is being conflated with the
question of limiting RFC illustrations to "ASCII art" vs. other graphic
formats. I don't think the two have anything important in common.
--
ition, I think you do your countrymen a disservice by claiming that
they are incapable of reading kanji printed in a Chinese-style font.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
___
Ietf mailing list
Ietf@ietf.org
tin and Greek are separate. Latin and Greek are not simply
glyph variants of one another.
You should admit that ISO 10646 useless for internationalization.
I do not. ISO 10646 is a cornerstone of modern software
internationalization.
I imagine this is off-topic for IETF.
what RFC 3066bis is really about is invited to
read it themselves:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt
I will not waste further keystrokes on this.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
points the first couple of times, and blew off
the restatements.
--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
___
I
believe the work may be of value to any entity (corporate or otherwise)
concerned with the identification of linguistic content.
--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.c
and it won't be off-topic any more. Just be
sure to check for prior art first, because you're likely not the first
person to try to solve this problem.
I would argue that if the data type has a 35 million year span, then
setting the baseline at 2000-01-01 seems arbitrary.
--
Now this is a reasonable use for this sort
> of language but I think that at least some of the 'may's should also
> be MAY.
We may want to add this as a data point in the continuing debate over
whether non-uppercased auxiliary verbs carry the same normative RFC 2119
meaning as u
dy appeared in
well-known and heavily cited RFCs (John's use case that launched the
present debate).
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/i
d "nepotism"
inappropriately to your "opponents" in this effort will only cause
people to take your effort less seriously, and may cause you personal
embarrassment as well (though this is probably mitigated by your use of
only a first name and pseudonym in your postings).
--
D
ier to criticize than learn, however, so I doubt you will do
this.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
_
what
was going on. It's conceivable that someone might have used this
high-profile mailing list as part of a spam, at some point, but to block
the entire domain is complete overkill. I'm no expert on e-mail
security, and I detest spam, but there is such a thing as a cure that is
wors
egal Provisions" document is 6 pages of legalese, and
I'm not enough of a lawyer to sort out which parts I'm supposed to
insert where, and what existing text I'm supposed to remove.
It would be nice if someone could provide guidance on (b), at least
until (a) is resolved.
-
best left to the future.
There is a block of 1024 code points *tentatively roadmapped* to "Sutton
SignWriting." That is very, very different from saying that "Unicode
has reserved N code points for our script."
--
Doug Ewell * Thornton, Colorado, USA * RFC 4
hored other RFCs, need to do to
allow the WG chairs to move *their* draft forward into IETF Last Call?
Our WG has stalled due to the uncertainty surrounding the legal
requirements and verbiage. None of us are attorneys, AFAIK, but all of
us would like to get our work done.
--
Doug
edit any more I-Ds after
draft-ietf-ltru-4645bis if I have to worry about my personal legal
liability if someone in the Working Group who contributed text has not
granted me sufficient IP rights.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http:
ze this may be the intent,
but this is legal wording, where the words are binding and not
the intent.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alv
ensus. Not all
"contributions" are positive or direct; an author might add wording
specifically to ward off a rogue interpretation that someone in the WG
"contributed." If you think this is improbable, read some of the
appeals that the IESG has had to address in the
Marshall Eubanks wrote:
Suppose that a major religious figure or a major movie star encouraged
their supporters to email the IETF list.
I thought Stallman was considered a major religious figure.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http
ssues and write
drafts before the first milestone.
--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
fiction. I don't object to this effective public
candidacy, but honesty in labeling might be called for.
--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailma
m.
Since tags of 1 character are never well-formed, I suggest that the
definition:
SYNTAX OCTET STRING (SIZE (0..60))
be amended to exclude the 1-character case. I assume that a zero-length
tag, while also not defined in RFC 4646, was included in the I-D to
allow the special case of
ller than X.Y and MUST support all versions
between and including that version and X.Y"?)
I remember MS-DOS software that would run under DOS version 3.3 or 5.0, but
not 4.0.
--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://users.adelphia.net/~dewell/
http
ate in the survey.
--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages
___
Ietf mailing
er one or both of these
approaches as an alternative to using RFC 1345 mnemonics for data entry.
Or, you can go ahead and use the mnemonics as they are, but resign
yourself to the fact that they will probably never be updated.
Speaking only for myself, as always.
--
Doug Ewell · Fullerton, Ca
stroke" and
j3 for "Greek iota below." This is what Ben is looking for.
--
Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand
n now beyond this obvious point?
-Doug Ewell
Fullerton, California
them regularly and
promptly!) so they are available in an easily accessible, central
location.
-Doug Ewell
Fullerton, California
ted in BCP 47.
RFC 4647, also part of BCP 47, provides guidelines for matching language
tags, and may benefit the SDP negotiation process described in the
draft.
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell
off the reference to the Registry and just say
the tag must conform to 5646 (or BCP 47). That will imply the use of the
Registry.
Thanks,
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell
-Original Message-
From: "Randall Gellens"
Sent: 2/23/2013 1:18
To:
That means essentially the same thing. Check to make sure your other reviewers
feel that wording is OK.
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell
-Original Message-
From: "Randall Gellens"
Sent: 2/23/2013 20:34
To: "Doug Ewell" ; "
had already
contacted the HR department of another contributor's employer, asking
them to professionally discipline the employee, because he had supported
an RFC 3683 PR-action against the first contributor. Full disclosure can
be a dangerous thing.
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell
'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in RFC 2119."
If a document wants to impart different meaning to one or more of the
words, wouldn't a
FCs) use only characters in a small and well-known fraction of the
Unicode code space. You might expect an RFC to contain non-ASCII
characters like á and — that are part of a well-known and widely used
subset like WGL4. You would not expect it to contain Egyptian
hieroglyphs or Vai syllabl
separate topics. You could have plain text encoded in
UTF-8. You could have HTML or PDF-A that uses nothing but ASCII
characters.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
ry, I don't understand this at all.
A space character (which looks like an ordinary U+0020 space to me, in
both the plain-text message I received and in the Web archive) got
erroneously converted to a question mark in Tim's plain-text mail.
How does this demonstrate anything about PDF?
ine
to me; only in Ohta-san's quoting of Tim's message do I see the question
mark.
Regardless of where the question mark came from, this still has nothing
to do with PDF. It has only to do with tools that misinterpret
character sets or transform plain text.
--
Doug Ewell | Tho
"bill manning" wrote:
ISO not withstanding, its still confusing if only because other
cultures use yyddmm.
Which cultures are those?
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://i
der than can
fit on the printed page. It is not an inherent flaw of HTML.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Masataka Ohta
wrote:
The problem with email is people use html way too much. TXT ->
HTML -> TXT does not work reliable. Too many one way
transformations.
That's enough to deny the following statement of Doug Ewell;
You could have HTML or PDF-A that uses nothing but ASCII char
important. PDF is a binary format and there are lots of other bytes in
this file with the high bit set, if we want to bring that up too.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://i
mbol.
Of course my old version of Distiller doesn't support PDF/A, as I'm sure
newer versions do, but you should get the idea: allowing RFCs to contain
non-ASCII does not imply changing the format from plain text, and vice
versa.
--
Doug Ewell | Thornton, Colorado, USA | http:/
can contain any Unicode character that an HTML document
can contain.
Note that I am not arguing in favor of plain text as the IETF standard.
I just want to keep this part of the discussion real. There is no
requirement anywhere that plain-text files may contain only ASCII
characters.
--
Doug Ewe
eature profile to be successful?
For an Engineering Task Force, this group sure does surprise me
sometimes with its logical reasoning.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages
ASCII" and "plain text."
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
documents more valuable
than 80% of the RFC series, will be converted and will exist in both old
and new formats LONG before there is any risk of irreversible
obsolescence.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://i
that you are more clever than me?
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
could be usable.
If you need really international scope, pure ASCII is the only choice.
For more information on this enlightening and forward-thinking approach
to internationalization, the interested reader may be directed to RFC
1815.
--
Doug Ewell | Thornton, Colorado, USA | http
use U+005C is unequivocally the backslash and U+00A5 is
unequivocally the yen sign. There are no context-dependent "duals" in
Unicode.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ htt
ould
be if they had stuck with ISO 2022 instead?
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
this difficult
to understand.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ays emerges from this joint character-set/RFC
format discussion, every time it comes up, is that someone feels there
should be one and only one process and tool set for writing I-Ds, and
someone else feels the need to wave the "Don't Tread on Me" flag in
protest.
--
Doug Ewell |
saying that I should not be able to see or use characters used
only in languages that I do not understand. I claim that a universal
character encoding is beneficial to all, and that it is my problem if I
don't have adequate fonts or knowledge to read the text.
--
Doug Ewell | Thornton, Colo
or more WG Internet-Drafts that went through to RFC, but have had
neither corporate sponsorship nor independent wealth necessary to attend
meetings. This situation is likely to continue, as people attending
meetings at reduced day-pass fees are excluded from Nomcom eligibility.
--
Doug Ewell
the DPE has been run.
At least on the surface, this does make it appear that the decision to
exclude day-pass attendees from NomCom, on the basis that such attendees
would not have the requisite experience, is driven by financial
considerations after all.
--
Doug Ewell | Thornton, Colorado
a WG on the belief that mailing-list-only participation
is important to the IETF. I am neither funded by my company to go on
round-the-world junkets, nor wealthy enough to afford them
out-of-pocket.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-lan
ear's question seems pertinent here.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
anks to (in alphabetical order): Tony Hansen, Thomson Martin
>and Barry Leiba for their weighty input to this document.
This doesn't look like alphabetical order to me. Is the parenthetical
comment really necessary when only three names are involved?
--
Doug Ewell | Thornton, Colorado,
can change them!
This is the eternal debate over Wikipedia: it's good because good people
can make it better, it's bad because bad people can make it worse.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd s
SM wrote:
> Quoting Doug Ewell [1]:
>
>"I thought it would be good to let the list know that these
> misconceptions exist and may be widespread, because of the wide
> use of Wikipedia"
I like Wikipedia and usually find its articles to be accurate. The
a
difficulty getting the desired results. Then again, I write code for a
living, so writing XML by hand isn't my idea of pain.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash
cesses that have no need for
top-notch security, and rely daily on FTP.
I often see comments on this list about whether the "outside world"
views the IETF as irrelevant. Declaring a commonly used, core process
or protocol as Historic because something better exists might be a
perfect
as Mykyta's) is how
aggressive some people might be in declaring a specification like FTP to
be superseded or obsolete. "Inappropriate for high-security uses" does
not by any means imply "inappropriate for all uses."
--
Doug Ewell | Thornton, Colorado, USA | http://w
e could possibly make a stronger case for classifying the
> RDP spec as Historic!
If "Historic" has taken on the connotation of "this spec is deprecated,
don't use it any more," then to the extent it is useful and deployed,
this would send the wrong message. Just like F
Donald Eastlake wrote:
Almost all registries I'm familiar with explicitly list unassigned
ranges.
The IANA Language Subtag Registry doesn't:
http://www.iana.org/assignments/language-subtag-registry
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 464
e same name probably carries some weight
for authors named "John Smith" or "Bob Miller." There are few enough
people named "Doug Ewell" in the world that the risk of ambiguity of
authorship seems much more remote than the risk to personal security if
too much pers
I wrote:
I [...] edited both RFC 4645 and 5646 as "Consultant."
s/5646/5645/
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
___
Ietf mailing list
Iet
hrase "or any other reason" seems unnecessarily open-ended, and may
invite abuse.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
___
Ietf mailing list
Ietf@
Anyway, what would you like to
> propose here?
I don’t have exact replacement wording. “Any other reason” could permit me to
propose deprecation or “historicization” of a protocol because I don’t like the
guy who created it, or because my company is promoting a rival protocol.
--
Doug Ewell |
increased by almost 15 times the number of languages that can be tagged
using this mechanism.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
___
Ietf mailing list
Iet
.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
e existing
documents to the end pages with the licensing info.
It would surprise me if changing all of the existing documents was
considered part of the scope of this suggestion.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/htm
ementations
in the drafts would have made a slow review and approval process even
slower.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ie
approved -- and let
others ignore it if they choose?
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
awful in any country.
This is completely different from the hundred or so "campaign" e-mails
sent to this list which said that all software patents are evil and all
software standards must be 100% patent-free.
--
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
http
1 - 100 of 127 matches
Mail list logo
