Marc
I opened the link on two different devices,
to see how the tables rendered.
On one (iPod touch with Safari), it worked reasonably.
The only problem was that the table columns were skewed
due to browser not using monospace fonts. Were the table more complex
or were there some truly wacky
That would work too. I added a third URL that returns
text/plain;format=fixed;line-length=72
http://ietf.implementers.org/fixed/rfc5928.txt
That is the worst option for my two devices.
On both devices the line wraps distort the tables beyond recognition.
Y(J)S
The time interval between ASCII text threads seems to be decreasing over time.
Perhaps when half of the traffic on the discussion list is related to this
question
something will finally be done.
Y(J)S
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
We, the RSOC, think this might be a good, simple first task for the
new RFC Series Editor ;-)
ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 Mobile: +1 415-370-4628
E-mail: o...@cisco.com URL: http://www.cisco.com/ipj
Skype:
--On Monday, November 28, 2011 02:45 -0800 Ole Jacobsen
o...@cisco.com wrote:
We, the RSOC, think this might be a good, simple first task
for the new RFC Series Editor ;-)
Especially given that, while we left omniscience off the public
requirements list, we expect any RSE appointee to
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
Please resolve these comments along with any other Last Call comments you
may receive.
Document:
On 2011-11-26 21:52, Yaakov Stein wrote:
That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8.
That wouldn't bother me much, but be careful what you wish form.
What we have been told is that the rationale behind the use of ASCII and
several other formats
is that they will
On 2011-11-27 09:20, Yaakov Stein wrote:
Dave
I agree that we are thinking as content creators, and that is the problem.
The requirement is not that we will be able to write a new document in 50 years
in the same format.
The requirement is that we should be able to read the documents written
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 01:52 AM, Yaakov Stein wrote:
Marc
I opened the link on two different devices,
to see how the tables rendered.
On one (iPod touch with Safari), it worked reasonably.
The only problem was that the table columns were skewed
due
On 2011-11-27 17:20, Marc Petit-Huguenin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem here is that RFC and Internet-Drafts are not plain ASCII. They are
technically in a special format that I would call line-printer ready text
file, and ASCII is the encoding, not the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 01:58 AM, Yaakov Stein wrote:
That would work too. I added a third URL that returns
text/plain;format=fixed;line-length=72
http://ietf.implementers.org/fixed/rfc5928.txt
That is the worst option for my two devices.
On both
On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote:
What's important is that things that *should* work well on small
displays, such a reflowing prose paragraphs, and re-pagination, do
so. This is where text/plain fails big (and HTML does not).
That's more of an attribute of the
On 2011-11-28 18:21, Ted Ts'o wrote:
On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote:
What's important is that things that *should* work well on small
displays, such a reflowing prose paragraphs, and re-pagination, do
so. This is where text/plain fails big (and HTML does not).
Hacking text display applications when HTML was designed for it already and
most RFC's natively generate HTML (xml2rfc), do we really have a problem to
solve?
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
On 2011-11-28 18:21, Ted Ts'o wrote:
On Mon, Nov 28, 2011 at 06:12:42PM +0100,
Hi,
Obviously, the key evolution is greater competition and market of display
devices, i.e. lack of a standard perhaps and patent restrictions which
promotes the propensity to just use HTML and HTML5 with OS file association
shell launching. This is especially the case since the 2006/2007
On 2011-11-28 18:46, Eric Burger wrote:
Hacking text display applications when HTML was designed for it already and
most RFC's natively generate HTML (xml2rfc), do we really have a problem to
solve?
...
If all documents were submitted in xml2rfc format (or something equally
expressive): not
Hi,
I just came across this (very long) thread started by Brian's post, and since
(as Robinson Tryon mentioned in a post already) libreoffice can convert
both .ppt and .pptx to .pdf, I've now set up the tools servers to convert
any .ppt and .pptx to .pdf as soon as they see them.
This means that
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
It requires a format that does allow reflowing and repagination. HTML does,
PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not).
text/plain is what we use, and that's a problem that'll need to be solved.
In practice,
The IETF legal counsel and insurance agent suggest that the IETF ought to have
an antitrust policy. To address this need, a lawyer is needed. As a way
forward, I suggest that IASA pay a lawyer to come up with an initial draft, and
then this draft be brought to the community for review and
On Mon, Nov 28, 2011 at 1:20 PM, Henrik Levkowetz hen...@levkowetz.com wrote:
Hi,
I just came across this (very long) thread started by Brian's post, and since
(as Robinson Tryon mentioned in a post already) libreoffice can convert
both .ppt and .pptx to .pdf, I've now set up the tools
Hi -
From: John C Klensin john-i...@jck.com
To: Ole Jacobsen o...@cisco.com
Cc: ietf@ietf.org
Sent: Monday, November 28, 2011 6:28 AM
Subject: RE: reading on small devices, was discouraged by .docx
...
On the other hand, I tried the PDF file out on one of those
small-screen devices and
I think that this is a very reasonable way to proceed.
On Mon, Nov 28, 2011 at 1:50 PM, IETF Chair ch...@ietf.org wrote:
The IETF legal counsel and insurance agent suggest that the IETF ought to
have an antitrust policy. To address this need, a lawyer is needed.
While _a_ lawyer is certainly
I support the general approach you outline in terms of process.
However it would really help me if you could write a non-normative
paragraph describing what you think is involved in an anti-trust policy?
___
Ietf mailing list
Ietf@ietf.org
a) It would seem sensible to leave the selection of the specific lawyer
to the IASA / IAOC.
b) I would hope that they will select a lawyer with specific exposure to
anti-trust issues. That may well turn out to be the existing IETF counsel.
Yours,
Joel
On 11/28/2011 1:57 PM, Marshall Eubanks
On Mon, Nov 28, 2011 at 01:50:51PM -0500, IETF Chair wrote:
The IETF legal counsel and insurance agent suggest that the IETF ought to
have an antitrust policy.
Did they say what problem it is they're worried about? I can't
respond to the merits without knowing why we might want to do this.
A
On Mon, Nov 28, 2011 at 10:50 AM, IETF Chair ch...@ietf.org wrote:
The IETF legal counsel and insurance agent suggest that the IETF ought to
have an antitrust policy. To address this need, a lawyer is needed. As a
way forward, I suggest that IASA pay a lawyer to come up with an initial
On 2011-11-28 19:24, Theodore Tso wrote:
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
It requires a format that does allow reflowing and repagination. HTML does,
PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not).
text/plain is what we use, and that's a problem
Sam:
I looked at the antitrust policies of other SDOs. They state the things that
are prohibited from discussion at their meetings and on their mail lists.
Russ
On Nov 28, 2011, at 1:59 PM, Sam Hartman wrote:
I support the general approach you outline in terms of process.
However it
Ted:
The IETF legal counsel and insurance agent suggest that the IETF ought to
have an antitrust policy. To address this need, a lawyer is needed. As a
way forward, I suggest that IASA pay a lawyer to come up with an initial
draft, and then this draft be brought to the community for
On 11/28/2011 10:59 AM, Sam Hartman wrote:.
However it would really help me if you could write a non-normative
paragraph describing what you think is involved in an anti-trust policy?
I'll suggest that that be the first work product of the attorney. At the least,
that will make sure that
Russ == Russ Housley hous...@vigilsec.com writes:
Russ Sam: I looked at the antitrust policies of other SDOs. They
Russ state the things that are prohibited from discussion at their
Russ meetings and on their mail lists.
OK, that sounds good. I definitely think we could use such a
On Mon, Nov 28, 2011 at 11:10 AM, IETF Chair ch...@ietf.org wrote:
Sorry, can you expand on the threat model here? Are we developing one in
order to defend against some specific worry about our not having one?
Because it has become best practice in other SDOs? Because the insurance
agent
--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
julian.resc...@gmx.de wrote:
That's more of an attribute of the text reader than any thing
else. I've had readers that reflow text just fine --- far
better than PDF, at any rate.
It requires a format that does allow reflowing and
In a different venue it was suggested to me that the group (a university-based
research consortium) NOT have a detailed anti-trust policy. The university's
law firm felt that we would be covered so long as we up front reminded the
participants that they were adults and needed to follow the
Dear Sam;
Wearing no hats. This is my own personal take on matters.
Also, I am not a lawyer, and this is not legal advice.
Please note that I, personally, do not
think that this will be trivial or easy to come up with.
On Mon, Nov 28, 2011 at 1:59 PM, Sam Hartman hartmans-i...@mit.edu wrote:
Julian Reschke wrote:
So, if we expect people to be able to read our documents in 5 years,
let alone 50, we need to stop using ASCII art.
ASCII arts is just fine.
Just that there there is an awful number of modern software
that is too stupid to display ASCII text with fixed pitch fonts.
On Mon, 28 Nov 2011, Sam Hartman wrote:
I support the general approach you outline in terms of process.
However it would really help me if you could write a non-normative
paragraph describing what you think is involved in an anti-trust policy?
Yes, please! Also, why it would be a different
On 2011-11-28 20:29, John C Klensin wrote:
--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
julian.resc...@gmx.de wrote:
That's more of an attribute of the text reader than any thing
else. I've had readers that reflow text just fine --- far
better than PDF, at any rate.
It
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code. Displaying HTML or XML
But our format currently is not reflowable.
On Mon, Nov 28, 2011 at 09:03:02PM +0100, Julian Reschke wrote:
No, it just shows that our format has been optimized for a use case
which almost nobody cares about anymore.
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying
The IETF legal counsel and insurance agent suggest that the IETF
ought to have an antitrust policy.
I would be interested in a brief explanation of why we need one now,
since we have gotten along without one for multiple decades.
Having worked with a lot of lawyers, my experience is that few
Ted, I like your approach of enquiring what problem we are striving to solve
and I like Russ's concise answer that it is Recent suits against other SDOs
that is the source of the concern
Russ, what are some of the Recent suits against other SDOs It would be
good to pin down the problem
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying about a use case
which isn't really a problem.
I read I-D's on my Kindle, when I can get the XML so I can turn it
into something legible. I'd read RFCs on it if there were a
On Mon, Nov 28, 2011 at 15:26, Ted Ts'o ty...@mit.edu wrote:
plain text works just *fine* on a desktop machines, which is what
implementors of network protocols generally use.
That's what I've been trying to tell them -- but some people love to
engineer so much that they don't know when to
Hi John,
On 2011-11-28 19:40 John C Klensin said the following:
--On Monday, November 28, 2011 19:20 +0100 Henrik Levkowetz
hen...@levkowetz.com wrote:
...
I've set the converter ('unoconv', which uses libreoffice) up
to convert to PDF/A, but the converter doesn't always fully
succeed
On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com wrote:
**
Ted, I like your approach of enquiring what problem we are striving to
solve and I like Russ's concise answer that it is Recent suits against
other SDOs that is the source of the concern
Russ, what are some of the
On 2011-11-29 08:10, IETF Chair wrote:
Ted:
The IETF legal counsel and insurance agent suggest that the IETF ought to
have an antitrust policy. To address this need, a lawyer is needed. As a
way forward, I suggest that IASA pay a lawyer to come up with an initial
draft, and then this
Julian Reschke wrote:
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code. Displaying HTML or XML
But our format
+1
It would be helpful in the non normative statement to the community to cite
what suits were are involved, what was the cause of action and what if any
decisions were rendered in these cases.
US antitrust law, for instance has specific exemptions for SDO's.
Henrik,
On 2011-11-29 07:20, Henrik Levkowetz wrote:
Hi,
I just came across this (very long) thread started by Brian's post,
I apologise to everybody. I should know better by now than to mention
anything to do with document format on this list.
and since
(as Robinson Tryon mentioned in a
On Mon, Nov 28, 2011 at 3:42 PM, Henrik Levkowetz hen...@levkowetz.com wrote:
The validator tells me that the files which validate does so against
both A-1a and A-1b, which if I understand things correctly indicate
that it's 1a-compliant, since 1b is a subset of 1a.
For those who like to
Hi John,
On 2011-11-28 21:50 John C Klensin said the following:
--On Monday, November 28, 2011 21:42 +0100 Henrik Levkowetz
hen...@levkowetz.com wrote:
One small suggestion, partially prompted by my attempts to
convert PDF and Postscript RFCs to PDF/A: when the converter
cannot or does
15 or 20 years ago, I might have been able to use one of those
small-screen devices. Nowadays - no way. If things are
displayed large enough to be legible the amount of vertical
scrolling makes reading anything longer than one (short)
sentence painfully slow.
But here's a solution: let's just
On October 10, 2011, the IESG issued a last call for comments regarding
draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for
Shared CGN Space). While the community did not display consensus supporting the
draft, it also did not display consensus against the draft.
On 2011-11-28 22:09, Martin Rex wrote:
Julian Reschke wrote:
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code.
+1 to all of John's points here. Especially about the essential nature
of lawyers - I've worked with plenty of them as well.
Ned
The IETF legal counsel and insurance agent suggest that the IETF
ought to have an antitrust policy.
I would be interested in a
I'm still lost.
What kind of things would the IETF have to prohibit discussion of, and
specifically things that would involve anti-trust.
Russ == Russ Housley hous...@vigilsec.com writes:
Russ I looked at the antitrust policies of other SDOs. They state
Russ the things that are
Michael == Michael Richardson m...@sandelman.ca writes:
Michael I'm still lost.
Michael What kind of things would the IETF have to prohibit
Michael discussion of, and specifically things that would involve
Michael anti-trust.
Cisco and Juniper folks form a design-team
Money for one discussions of product pricing and or costs for instance.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Michael Richardson
Sent: Monday, November 28, 2011 5:12 PM
To: Russ Housley
Cc: Sam Hartman; IETF
Subject: Re: An
In my opinion, having a designated space is better than squat space, given
that we we already know that squat space is being used. The argument that it
extends the life of IPv4 is, IMHO, of limited value; yes, it allows operators
to keep their IPv4 service running; given the number of CPE
On 11/28/2011 12:31 PM, John Levine wrote:
I would be interested in a brief explanation of why we need one now,
since we have gotten along without one for multiple decades.
Having worked with a lot of lawyers, my experience is that few lawyers
understand cost-benefit tradeoffs, and often
On Mon, Nov 28, 2011 at 3:07 PM, Fred Baker f...@cisco.com wrote:
In my opinion, having a designated space is better than squat space, given
that we we already know that squat space is being used. The argument that it
extends the life of IPv4 is, IMHO, of limited value; yes, it allows
Here is one lawsuit that I noticed in the press this summer:
http://www.cellular-news.com/story/50118.php
On Nov 28, 2011, at 3:35 PM, GTW wrote:
Ted, I like your approach of enquiring what problem we are striving to solve
and I like Russ's concise answer that it is Recent suits against
In message 2028203627.3441.qm...@joyce.lan, John Levine writes:
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying about a use case
which isn't really a problem.
I read I-D's on my Kindle, when I can get the XML so I
The admin plenary minutes from IETF 82 have been posted:
http://www.ietf.org/proceedings/82/minutes/plenaryw.txt
Many thanks to Alexa for taking the notes. The name of one speaker is unknown.
If you know the name, please share so that I can make them complete. Also, if
you notice any errors,
From: Marshall Eubanks marshall.euba...@gmail.com
As you may know, SDO's have a certain protection against antitrust
actions, but that is not absolute, and can be lost if the SDO behaves
inappropriately.
Ironically, it was concern about anti-trust suits which led to the
Here is some relevant language from the Complaint:
100. By their failures to monitor and enforce the SSO Rules, and to
respond to TruePosition's specific complaints concerning violations of the
SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and
complicit in, the abuse of
On 2011-11-29 14:51, John Levine wrote:
Here is some relevant language from the Complaint:
100. By their failures to monitor and enforce the SSO Rules, and to
respond to TruePosition's specific complaints concerning violations of the
SSO Rules, 3GPP and ETSI have acquiesced in, are
As I read that, we'd be much better off having no antitrust policy
at all. Any volunteers to monitor and enforce whatever policy our
lawyer invents?
John, if they'd had no relevant rules, it would probably have read
100. By their failures to promulgate appropriate SSO Rules, ...
Quite
I refrained from commenting during the IETF Last Call, and I think it might
help the IESG to reach the least bad decision if I say why.
This whole proposal will *never* be palatable to me. However, it may be
reasonable for the IETF to lay down appropriate restrictions, even though
we know that
I agree generally with Brian except for the 2860 part. I would not want
to have seen IANA put on the spot for this, even if the IAB had been
willing to take responsibility for it.
Meanwhile I will say once again that capitulating here is wrong on many
levels. First there is the whole, They made
Ironically, it was concern about anti-trust suits which led to the creation
of the ISOC, and the re-homing of the IETF under the ISOC, in the first place
(back in the fall of 1989).
Not only that. The current IETF rules were specifically designed with antitrust
considerations in mind. The
At 10:50 28-11-2011, IETF Chair wrote:
The IETF legal counsel and insurance agent suggest that the IETF
ought to have an antitrust policy. To address this need, a lawyer
is needed. As a way forward, I suggest that IASA pay a lawyer to
come up with an initial draft, and then this draft be
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying about a use case
which isn't really a problem.
I, for one, regularly (attempt to) read RFCs and other standards on small
devices.
I do this because I have stopped shlepping
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based
Management Overview'
draft-ietf-mpls-tp-mib-management-overview-05.txt as an Informational
RFC
The IESG
The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Multi-Instance Extensions'
draft-ietf-ospf-multi-instance-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Location Configuration Extensions for Policy Management'
draft-ietf-geopriv-policy-uri-04.txt as a Proposed Standard
This is a second last call to verify a change in
The Yet Another Mail (yam) working group in the Applications Area has
concluded. The IESG contact persons are Pete Resnick and Peter Saint-Andre.
The mailing list will remain active.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
The IESG has received a request from an individual submitter to consider
the following document:
- 'URI Template'
draft-gregorio-uritemplate-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send
A new Request for Comments is now available in online RFC libraries.
RFC 6433
Title: Requirements for a Working Group
Milestones Tool
Author: P. Hoffman
Status: Informational
Stream: IETF
Date:
A new Request for Comments is now available in online RFC libraries.
BCP 171
RFC 6441
Title: Time to Remove Filters for
Previously Unallocated IPv4 /8s
Author: L. Vegoda
Status: Best Current Practice
A new Request for Comments is now available in online RFC libraries.
RFC 6456
Title: Multi-Segment Pseudowires in Passive Optical
Networks
Author: H. Li, R. Zheng,
A. Farrel
Status: Informational
82 matches
Mail list logo
