+1. This is the only way that sorts properly, so the only one that makes sense.
David
On Sat, Mar 13, 2010 at 10:06 AM, Marshall Eubanks wrote:
>
>
> On Mar 13, 2010, at 9:51 AM, Cullen Jennings wrote:
>
>>
>> I just got abused by someone reading the IESG web pages and pointing out
>> dates like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2010 07:25 AM, Cullen Jennings wrote:
>
> Wow - I never imagined such a rapid response to this question. Thanks.
>
> I've replied with roughly "Yep, they might be a bit confusing but everything
> else is worse so that's what we use".
Anot
What I find rather puzzling here is that most of the defenders of the
status quo are saying 'document format is really no big deal, why make
a fuss'. And the contrary argument is 'Actually, this is a very big
deal to us, we care a lot about how the documents look and the type of
tools that can be u
In the UK we use day-month-year. I have never seen year-day-month.
day-month-year and year-month-day are both logical formats I can use.
the us norm of year-day-month is the only one that I find profoundly
illogical. I would usually require it to be re-written in an
unambiguous form in company do
--On Saturday, March 13, 2010 15:21 -0500 "Phillips, Addison"
wrote:
> (from digest)
>
>>
>> ISO not withstanding, its still confusing if only because
>> other cultures use yyddmm. If the IETF website used
>> something like ISO-2010-01-02 maybe.
>
> Actually, for culturally-formatted date
As expected, I completely agree. It was only the sweeping
statement to which I was taking exception. I'm certainly not
aware of anyplace where ydm is the officially-preferred format
although, like you, I wouldn't be especially surprised if
someone found one.
john
--On Saturday, March 13, 2
So what has me annoyed about the IAB advice is that they gave advice
about a particular means where they should have instead specified a
requirement.
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07028.html
" The reasoning is of a technological nature and is as follows. A
single
Funny, I don't think anyone was suggesting PDF/A. The format most people
have been suggesting is HTML. Donald brought up PDF/A as a strawman at the
start of this discussion.
And the fact is that even though many, many people submit HTML versions of
their drafts it is not possible to retrieve them
I agree with Sam that it might be a sensible modification of the existing
process.
However, it is irrelevant to the current discussion since the IESG is not at
current permitted to make such a statement.
The main argument against modification might well be the very fact that it
would allow appeal
You can submit the HTML, the problem is that it seems to go in the bit
bucket.
Since the preferred submission formats are XML or nroff, I see no reason
that the HTML version could not be generated from the XML.
The problem seems to be that the RFC editor insists on using the XML to
generate nroff
>From RFC 2026
" At all stages of the appeals process, the individuals or bodies
responsible for making the decisions have the discretion to define
the specific procedures they will follow in the process of making
their decision."
Suggest that before anyone suggests modifying process the
The second attachment is a macro that can be used in the wiki to annotate the
dates, something like this:
[[Date(2010-01-02)]]
For example with a format of "%a, %d %b %Y", the wiki will display this:
Fri, 01 Jan 2010
Uhm, does it work in .txt files? What about PDF-A? :-)
Robert
_
Phillip Hallam-Baker wrote:
What I find rather puzzling here is that most of the defenders of the
status quo are saying 'document format is really no big deal, why make
a fuss'.
?? I haven't seen anybody argue that, actually, and it would
be odd if they did.
I am in class E. I find being re
On 14.03.2010 19:45, Phillip Hallam-Baker wrote:
You can submit the HTML, the problem is that it seems to go in the bit
bucket.
Since the preferred submission formats are XML or nroff, I see no reason
that the HTML version could not be generated from the XML.
The problem seems to be that the RF
On 3/15/2010 8:53 AM, Melinda Shore wrote:
> Phillip Hallam-Baker wrote:
>> What I find rather puzzling here is that most of the defenders of the
>> status quo are saying 'document format is really no big deal, why make
>> a fuss'.
>
> ?? I haven't seen anybody argue that, actually, and it would
On 03/15/2010 08:39 AM, Robert Kisteleki wrote:
>> The second attachment is a macro that can be used in the wiki to
>> annotate the
>> dates, something like this:
>>
>> [[Date(2010-01-02)]]
>>
>> For example with a format of "%a, %d %b %Y", the wiki will display this:
>>
>> Fri, 01 Jan 2010
>
> Uh
On 15.03.2010 17:00, todd glassey wrote:
...
Sorry - but the IETF should have moved into Web Based automated document
submission years ago.
...
It did.
Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/iet
On 3/13/2010 3:35 PM, John C Klensin wrote:
>
>
> --On Saturday, March 13, 2010 15:21 -0500 "Phillips, Addison"
> wrote:
This is a prime example of the IETF's waste of time and energy. The ISO
8601 date standard is the obvious answer and yet this convo is still
going...
Todd
>
>> (from digest
On 3/15/2010 9:07 AM, Julian Reschke wrote:
> On 15.03.2010 17:00, todd glassey wrote:
>> ...
>> Sorry - but the IETF should have moved into Web Based automated document
>> submission years ago.
>> ...
>
> It did.
>
> Best regards, Julian
Julian - if this was done properly there would be no need
So there was this article in the Mercury News this AM about the Internet
winning the 2010 Nobel Peace Prize. Vint and Len K and the remaining
founders should be very pleased with this.
My take is its about time someone noticed at a global level what the
technology explosion has done to protecting
On 15.03.2010 17:16, todd glassey wrote:
On 3/15/2010 9:07 AM, Julian Reschke wrote:
On 15.03.2010 17:00, todd glassey wrote:
...
Sorry - but the IETF should have moved into Web Based automated document
submission years ago.
...
It did.
Best regards, Julian
Julian - if this was done proper
> So there was this article in the Mercury News this AM
> about the Internet winning the 2010 Nobel Peace Prize
Just a nomination, one of 237. Though the one getting
the most buzz it would appear. (The full list is apparently
not published.)
--
Christopher Dearlove
Technology Leader, Communicati
Phillip Hallam-Baker wrote:
> 9) Ability to code names properly
> 10) Ability to write an intelligible document on internationalization
> issues
> ...
> 8, 9, 10) Only supported by HTML.
I continue to be puzzled by statements like this. A plain-text file
encoded in UTF-8 can contain any Unicode
On 3/11/2010 7:32 AM, Donald Eastlake wrote:
Periodically, there are flame wars on the IETF mailing list that the
IETF should / shouldn't...
Mayhap we should create a FAQ wiki that captures the essence of these debates,
so that we can simply cite the relevant entry when the topic arises, an
Author: Jeffrey Williams ?
J
On Mon, Mar 15, 2010 at 10:49 AM, Dave CROCKER wrote:
>
>
> On 3/11/2010 7:32 AM, Donald Eastlake wrote:
>>
>> Periodically, there are flame wars on the IETF mailing list that the
>> IETF should / shouldn't...
>
>
> Mayhap we should create a FAQ wiki that captures th
On 3/15/2010 10:36 AM, Jorge Amodio wrote:
Author: Jeffrey Williams ?
A wiki's on-going peer-review ensure quick correction.
There is also some benefit in requiring an IETF web login.
d/
On Mon, Mar 15, 2010 at 10:49 AM, Dave CROCKER wrote:
On 3/11/2010 7:32 AM, Donald Eastlake wrote:
Phillip Hallam-Baker wrote:
...
> Before you answer that, here is a list of consensus requirements on
> the document format:
>
> 1) Easy to generate
> 2) Readily supported by a wide range of authoring tools
WYSIWYG authoring, IMO, ought to be required if we're claiming to climb
out of the stone
Julian Reschke wrote:
>
> On 14.03.2010 19:45, Phillip Hallam-Baker wrote:
> >
> > Since the preferred submission formats are XML or nroff, I see no reason
> > that the HTML version could not be generated from the XML.
Are there numbers available from the RFC Editor about the
use of XML vs nroff
Julian Reschke wrote:
>
> On 13.03.2010 16:13, bill manning wrote:
> > ISO not withstanding, its still confusing if only because other cultures use
> > yyddmm. If the IETF website used something like ISO-2010-01-02 maybe.
> >
> > This format is less confusing: 02jan2010
>
> As far as I recall
On 15.03.2010 21:01, Martin Rex wrote:
...
Are there numbers available from the RFC Editor about the
use of XML vs nroff for document subissions during the past 1/2 years?
...
That would be interesting.
...
So the big plus for the ASCII document version is that an author can
spend his time en
Phillip Hallam-Baker wrote:
> Before you answer that, here is a list of consensus requirements on
> the document format:
The fundamental consensus requirement is that the document format MUST
be widely (and internationally) legible.
The internationalization requirement automatically excludes non
Julian Reschke wrote:
>
> > Printing the documents with Microsoft Word is not that difficult.
> > Load it as .txt, remove two newlines at the beginning of the
> > title page, select page margins at 1"/1" left&right, font
> > courier new and font size 10 throughout should work on A4 paper.
> > Prin
On 15.03.2010 22:08, Masataka Ohta wrote:
Phillip Hallam-Baker wrote:
Before you answer that, here is a list of consensus requirements on
the document format:
The fundamental consensus requirement is that the document format MUST
be widely (and internationally) legible.
The internationalizat
On 15.03.2010 22:19, Martin Rex wrote:
...
It needs a painful lot of work to make free-floating formating
not come out with poor results. When I do the above, an ascii
arts with 3 lines of text and a box around is broken over from
page8->page9 for http://greenbytes.de/tech/webdav/rfc2616.html
..
On 15.03.2010 21:31, Martin Rex wrote:
...
IETF Meeting agendas have long been using 24h, but desperately
lacks the GMT offset for the Meeting location.
...
Agreed.
In the meantime, the ICS files generated on tools.ietf.org are useful to
get reliable time information.
Best regards, Julian
_
Julian Reschke wrote:
>> The internationalization requirement automatically excludes non-ASCII
>> characters.
> How so?
People can read ASCII internationally. Even though, in Japan, back
slash characters are displayed as JPY mark in most environment,
Japanese know how to read them.
People can r
On 16.03.2010 00:02, Masataka Ohta wrote:
Julian Reschke wrote:
The internationalization requirement automatically excludes non-ASCII
characters.
How so?
People can read ASCII internationally. Even though, in Japan, back
slash characters are displayed as JPY mark in most environment,
Japan
Phillip Hallam-Baker wrote:
As was discussed already in this ML, RPKI is useless.
Even if an AS owning an address block is securely known, it does
not secure routing to the address block through other ASes.
Masataka Ohta
__
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-nsis-n
Julian Reschke wrote:
>> People can read/edit their local characters.
>> People can't read/edit local characters of other people.
> A conservative approach would be:
>
> 1) allow non-ASCII contact information *in addition* to the ASCII version
>
> 2) allow non-ASCII in I18N example
No. The con
Phillip Hallam-Baker wrote:
> Since nobody was using teleprinters 500 years ago the introduction of
> them here as a point of difference is ridiculous.
I can't see your point.
Are you begging our pardon and withdraw your stupid statement of
"being able to interpret them in 1000 years time"?
Or?
On 16.03.2010 00:37, Masataka Ohta wrote:
Julian Reschke wrote:
People can read/edit their local characters.
People can't read/edit local characters of other people.
A conservative approach would be:
1) allow non-ASCII contact information *in addition* to the ASCII version
2) allow non-ASC
Phillip Hallam-Baker;
I can understand that you are seriously worrying about archaeology
of year 3010 and beyond.
However, I'm afraid no one else is interested in.
Masataka Ohta
___
Ietf mailing
An editorial comment on Section 2.
Section 2
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. A Message-Authenticator
attribute MUST be included so as to provide per-packet authentication
and integrity protection. A s
On 2010-03-16 05:42, Doug Ewell wrote:
...
> 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.
That requirement is explicit
Julian Reschke wrote:
> *A* conservative approach != The *most* conservative approach.
Your approach is no conservative.
>> Greek capital letter 'A', which is identical to Latin chapital
>> letter 'A', is already to much.
> I don't see your point.
It's your problem.
> I don't think anythi
I reviewed the document draft-ietf-isms-dtls-tm-09.txt in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on docum
47 matches
Mail list logo
