Re: More liberal draft formatting standards required

2009-07-02 Thread Stefan Santesson
On 09-07-02 1:00 AM, Randy Presuhn randy_pres...@mindspring.com wrote:

 One of the advantages of nroff input is that it *is* human readable.  (To me
 it seems much easier to read than HTML, but that's not the issue here.)
 To generate formatted output (in a variety of possible formats) the freely-
 available groff program works well.

Yes, and that is what I used for many many years until I got tired of saving
to a temporary files and to use command line in endless iterations until I
got all page breaks and other formatting exactly as I wanted them.

I always wanted a tool where I could have the .nroff version and the text
version in two parallel windows, to immediately see the effect of any
changes in .nroff, hence I wrote my own. Mostly for the fun of it. But the
more I use that feature, the more I learned to like it end depend on it.

/Stefan


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Henrik Levkowetz


On 2009-07-01 22:38 Martin Rex said the following:

 
 While I participated IETF Meetings in 1995-98, I often used pstools to
 create printed copies (2-up) of RFCs and Internet Drafts for reading
 while travelling and during meetings (didn't have a laptop).
 
 I used a wrapping perl-script because it was a little difficult
 to cope with some documents (varying page lengths and no page feed
 control character, plus occasionally Word-corrupted quote characters).
 
 Maybe the IETF could provide a conversion page on their Web-Server
 that can convert RFCs and Internet Drafts on the fly from their
 original ASCII-form into page-formatted PDF files, something like
 you post an URL in a Form, it gives you back a PDF.

Yes. Something like this already exists, has been available as an online
service since 2005, and was created explicitly to help people print documents:

  http://tools.ietf.org/pdf/

Regards,

Henrik
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


RE: More liberal draft formatting standards required

2009-07-02 Thread Yaakov Stein
Have a look at Dave Mills recent remarks on the NTP list :
https://lists.ntp.org/pipermail/ntpwg/2009-June/001519.html

Due to his diminished eyesight he can't handle the text
of the document he is co-authoring without significant preprocessing.

Y(J)S


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda 
Shore
Sent: Thursday, July 02, 2009 02:23
To: Randy Presuhn
Cc: IETF Discussion Mailing List
Subject: Re: More liberal draft formatting standards required

Randy Presuhn wrote:
 I don't know.  I prefer vi.

You can run nroff on a buffer inside of both vi and emacs
and get the output in another buffer.

I've read internet drafts on a variety of handheld devices,
from the old Sharp Wizards to Palm Pilots to a Blackberry,
and I very much appreciate having a lowest-common-denominator
document format.  The only drawback has been the fixed line
length - it can be slightly annoying for text but it renders
ascii graphics completely useless on a narrower screen.  On
balance I think it's a reasonable tradeoff, though.  And
personally, I'm grateful that such a wide variety of tools
can be used to generate conforming drafts - I think that it
helps keep the process just a little more open.

Melinda
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Iljitsch van Beijnum

On 2 jul 2009, at 10:47, Yaakov Stein wrote:


Due to his diminished eyesight he can't handle the text
of the document he is co-authoring without significant preprocessing.


Ok if we're going to have this discussion again:

PDF is a way to display documents on the screen the same way that  
would appear on paper. Since screen and paper have different  
limitations, that usually entails pretty significant compromises. It's  
also extremely hard to build home grown tools to scrape PDF files.  
Even copy/paste from PDF is a challenge. So making PDF the  
authoritative version (let alone the only version) we create more  
problems than we solve. Exit PDF.


A much better solution would be HTML, if it's sufficiently  
constrained. HTML allows for the reflowing of text, solving issues  
with text and screen sizes. It's also extremely widely implemented, so  
it's easy to display reasonably well without special tools. It also  
allows for semantic tagging, allowing for easy scraping.


Last but not least, just filter out anything between  and  and  
replace a few xxx; sequences and you're back to plain text. We could  
probably even format RFCs such that if you remove the HTML, you're  
left with the current ASCII format.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


RE: More liberal draft formatting standards required

2009-07-02 Thread Yaakov Stein
The limitations of ASCII format have been discussed here numerous times.
For example, see the lengthy thread last year on draft-ash-alt-formats (now 
expired).

Many people have proposed modern approaches that comply with the constraints.
Going back a generation or two to nroff seems to me to be a step in the wrong 
direction.

Y(J)S

-Original Message-
From: Douglas Otis [mailto:do...@mail-abuse.org] 
Sent: Thursday, July 02, 2009 08:19
To: alh-i...@tndh.net
Cc: 'Theodore Tso'; Yaakov Stein; 'IETF Discussion Mailing List'
Subject: Re: More liberal draft formatting standards required


On Jul 1, 2009, at 10:58 AM, Tony Hain wrote:

 An alternative would be for some xml expert to fix xml2rfc to parse  
 through the xml output of Word. If that happened, then the  
 configuration options described in RFC 3285 would allow for wysiwyg  
 editing, and I would update 3285 to reflect the xml output process.  
 I realize that is a vendor specific option, but it happens to be a  
 widely available one.


Reasons for wanting more than just plain text documents is to permit  
inclusion of charts, graphs, and tables, for a visual society.  A safe  
way to provide this type of output using stable open-source code would  
be with roff preprocessors, like eqn, pic, tbl.

Word's closed code is continuously changing.   Availability of this  
closed application depends upon OS compatibility and version  
regressions.   Both are moving targets.  In addition, Word formats  
permit inclusion of potentially destructive scripts within highly  
flexible and obfuscating structures.   troff normally outputs .ps and  
is supported by various utilities like X viewers in open source.  Unix  
based OSs like OSX and Linux still support this document format, where  
grohtml can generate HTML output. The disadvantage of using the roff  
approach has been a lack of IETF boilerplate pre-processors.  Merging  
XML structures could be combined with powerful roff presentation  
utilities to generate IETF documents.

In many respects, roff offers simpler and proven stable formats.  The  
present xml2rfc utilities do not offer wysiwyg.   Combining custom pre- 
processors and visualization utilities, the roff suite offers greater  
security, stability and versatility for all OSes and media  
presentations types, along with iterative wysiwyg modes of operation.   
There would be little difference using roff tools from using xml2rfc,  
however the results could show a marked visual improvement.  A desire  
for security might even foster a resurgence in roff tools to leverage  
proven and stable document generation.

Everything old is new again.

-Doug




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Doug Ewell

Douglas Otis dotis at mail dash abuse dot org wrote:

Word's closed code is continuously changing.   Availability of this 
closed application depends upon OS compatibility and version 
regressions.   Both are moving targets.  In addition, Word formats 
permit inclusion of potentially destructive scripts within highly 
flexible and obfuscating structures...


I didn't hear anyone ask to make evil Word from evil Microsoft the 
standard format for I-Ds and RFCs.  I did hear a suggestion to enhance 
xml2rfc so it can interpret the XML generated by evil Word.  The 
resulting code generated by xml2rfc would presumably have all of the 
evilness purged.


--
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/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Julian Reschke

Doug Ewell wrote:

Douglas Otis dotis at mail dash abuse dot org wrote:

Word's closed code is continuously changing.   Availability of this 
closed application depends upon OS compatibility and version 
regressions.   Both are moving targets.  In addition, Word formats 
permit inclusion of potentially destructive scripts within highly 
flexible and obfuscating structures...


I didn't hear anyone ask to make evil Word from evil Microsoft the 
standard format for I-Ds and RFCs.  I did hear a suggestion to enhance 
xml2rfc so it can interpret the XML generated by evil Word.  The 
resulting code generated by xml2rfc would presumably have all of the 
evilness purged.

...


Just because xml2rfc happens to use a base XML format doesn't mean it 
can be easily changed to use a different XML vocabulary.


A conversion tool (reading Word, generating xml2rfc XML source) would 
make more sense, IMHO. That being said, I looked at this several years 
ago, and the 2003 Word XML format was a pain to process, and also lacks 
much of the interesting stuff (such as blbliographical information).


BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Tim Bray
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote:

 A much better solution would be HTML, if it's sufficiently constrained. HTML
 allows for the reflowing of text, solving issues with text and screen sizes.
 It's also extremely widely implemented, so it's easy to display reasonably
 well without special tools. It also allows for semantic tagging, allowing
 for easy scraping.

This seems obviously true everywhere outside the IETF mailing list.

 Last but not least, just filter out anything between  and  and replace a
 few xxx; sequences and you're back to plain text. We could probably even
 format RFCs such that if you remove the HTML, you're left with the current
 ASCII format.

Yes and no.  Yes, removing markup leaves useful text, but no, it
wouldn't be anything like the line-broken, paginated,
headered-and-footered, legacy text format.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Stewart Bryant

Tim Bray wrote:

On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote:

  

A much better solution would be HTML, if it's sufficiently constrained. HTML
allows for the reflowing of text, solving issues with text and screen sizes.
It's also extremely widely implemented, so it's easy to display reasonably
well without special tools. It also allows for semantic tagging, allowing
for easy scraping.



This seems obviously true everywhere outside the IETF mailing list.
  
The showstopper has always been with figures which need to do in 
separate  files.

How do you  manipulate the collection of files as a single object?

At least with pdf you know you have the whole thing.

Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Ted Hardie
At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
 for wanting more than just plain text documents is to permit 
inclusion of charts, graphs, and tables, for a visual society


It seems to me that where this discussion has faltered before is
on whether this is, in fact, a requirement.  In the past, multiple
people have argued that switching to a mode in which understanding
the figures is necessary to understanding the protocol would
be a step away from clarity, searchability, and inclusiveness.
We have agreed to do it in some places in the past, but I
believe there has been no previous rough consensus that it
should be the default.

If we are going to re-run this discussion, can we first check
on the consensus on this requirement?  If we don't agree
here, the chance of this run concluding seems no better than
any of the previous runs at the problem.  The discussion
just fragments into tool use, printer capabilities, and various
distractions.

regards,
Ted Hardie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Marshall Eubanks


On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:


At 10:19 PM -0700 7/1/09, Douglas Otis wrote:

for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society



It seems to me that where this discussion has faltered before is
on whether this is, in fact, a requirement.


You are exactly correct, and I can recall several interminable  
discussions of this.


To save time, I would suggest adopting the Patent Office rules on  
Perpetual Motion. People advocating for a change to facilitate figures  
(or to allow complicated math, such as tensor analysis) should have an  
existence proof, i.e., a document that requires the change to be  
published. (A document that left the IETF to be published elsewhere  
for this reason would also do.)


Regards
Marshall


In the past, multiple
people have argued that switching to a mode in which understanding
the figures is necessary to understanding the protocol would
be a step away from clarity, searchability, and inclusiveness.
We have agreed to do it in some places in the past, but I
believe there has been no previous rough consensus that it
should be the default.

If we are going to re-run this discussion, can we first check
on the consensus on this requirement?  If we don't agree
here, the chance of this run concluding seems no better than
any of the previous runs at the problem.  The discussion
just fragments into tool use, printer capabilities, and various
distractions.

regards,
Ted Hardie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Regards
Marshall Eubanks
CEO / AmericaFree.TV



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Iljitsch van Beijnum

On 2 jul 2009, at 17:05, Stewart Bryant wrote:


A much better solution would be HTML



This seems obviously true everywhere outside the IETF mailing list.



The showstopper has always been with figures which need to do in  
separate  files. How do you  manipulate the collection of files as a  
single object?


Multiple files seems problematic.

However, we can stick with ASCII art even if we adopt HTML.


┏ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━━━┯━━━┓

   ┃ An influx of a (hopefully limited) set │ of unicode symbols┃
   ┃ could allow for more expressiveness in │ this area.┃

┗ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━━━┷━━━┛___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Ole Jacobsen

Iljitsch,

That box shows up as complete gibberish in a plain-text mail reader 
(pine in my case), which sort of proves the point about ASCII. What 
you sent was certainly not ASCII.

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



On Thu, 2 Jul 2009, Iljitsch van Beijnum wrote:

 On 2 jul 2009, at 17:05, Stewart Bryant wrote:
 
   A much better solution would be HTML
 
  This seems obviously true everywhere outside the IETF mailing list.
 
 
 The showstopper has always been with figures which need to do in separate
 files. How do you  manipulate the collection of files as a single object?
 
 Multiple files seems problematic.
 
 However, we can stick with ASCII art even if we adopt HTML.
 
   
 ???
   ??? An influx of a (hopefully limited) set ??? of unicode symbols???
   ??? could allow for more expressiveness in ??? this area.???
   
 ???
 ___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Julian Reschke

Iljitsch van Beijnum wrote:

  On 2 jul 2009, at 17:05, Stewart Bryant wrote:

A much better solution would be HTML 


This seems obviously true everywhere outside the IETF mailing list. 


The showstopper has always been with figures which need to do in 
separate  files. How do you  manipulate the collection of files as a 
single object?


Multiple files seems problematic.

However, we can stick with ASCII art even if we adopt HTML.
...


Indeed. Let's keep these discussions separate.

BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Douglas Otis


On Jul 2, 2009, at 9:22 AM, Marshall Eubanks wrote:



On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:


At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
for wanting more than just plain text documents is to permit  
inclusion of charts, graphs, and tables, for a visual society


It seems to me that where this discussion has faltered before is on  
whether this is, in fact, a requirement.


You are exactly correct, and I can recall several interminable  
discussions of this.


To save time, I would suggest adopting the Patent Office rules on  
Perpetual Motion. People advocating for a change to facilitate  
figures (or to allow complicated math, such as tensor analysis)  
should have an existence proof, i.e., a document that requires the  
change to be published. (A document that left the IETF to be  
published elsewhere for this reason would also do.)


What appears to be missed in these conversations represents a  
dissatisfaction of the generation tools and output quality, which is  
easily shared.  There is good reason to avoid closed source generation  
tools, however the IETF has already employed and permitted the use of  
roff inputs and outputs, which appears to offer a reasonable means to  
satisfy the many requirements already in place.


A suggestion to use Word XML outputs as a means of providing WISIWYG  
operation misses what is currently in place within xml2rfc needed to  
generate tables, state diagrams, and graphs.  Yes, these elements are  
_currently_ contained within existing RFCs,  but  in ASCII form.  Even  
though these elements are structured using ASCII, textual processing  
must still accommodate special handling of these clumsy visual elements.


Although I am not blind, the simple instructions required by roff  
tools should allow those visually impaired a superior means for  
understanding the intent of visual graphics, rather than guessing what  
a series of white-space and characters are attempting to convey within  
diagrams or equations.


In addition, there are currently several RFCs already created using  
roff, as were my first attempts at writing I-Ds.  Due to IETF's  
current level of support for xml2rfc, this mode of input now offers an  
easier means to generate acceptable output.  IMHO, roff tools can  
still offer higher quality output that is more compatible with various  
presentation media than outputs generated from xml2rfc.


Perhaps the IETF may wish to better retain the older roff methods by  
offering better boilerplate and processing support for this currently  
acceptable method for generating I-Ds and RFCs.  A wiki style web-page  
with IETF custom roff pre-preprocessors could facilitate roff inputs  
for the creation of ID and RFC documents.  The availability of roff to  
html output should also make creating previews as a type of iterative  
WISIWYG mode of creation possible.  This would be no different than  
the steps used with xml2rfc.


IIRC, .ps generated from roff tools are still acceptable inputs as  
well, although I expect the current publishing automation is likely to  
balk at output from these older methods.  Too bad though.


-Doug


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Stewart Bryant




To save time, I would suggest adopting the Patent Office rules on 
Perpetual Motion. People advocating for a change to facilitate figures 
(or to allow complicated math, such as tensor analysis) should have an 
existence proof, i.e., a document that requires the change to be 
published. (A document that left the IETF to be published elsewhere 
for this reason would also do.)

RFC1305 which states

Note: This document consists of an approximate rendering in ASCII of the
PostScript document of the same name. It is provided for convenience and
for use in searches, etc. However, most tables, figures, equations and
captions have not been rendered and the pagination and section headings
are not available.

- Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread Marshall Eubanks


On Jul 2, 2009, at 2:01 PM, Stewart Bryant wrote:





To save time, I would suggest adopting the Patent Office rules on  
Perpetual Motion. People advocating for a change to facilitate  
figures (or to allow complicated math, such as tensor analysis)  
should have an existence proof, i.e., a document that requires the  
change to be published. (A document that left the IETF to be  
published elsewhere for this reason would also do.)

RFC1305 which states

Note: This document consists of an approximate rendering in ASCII of  
the
PostScript document of the same name. It is provided for convenience  
and

for use in searches, etc. However, most tables, figures, equations and
captions have not been rendered and the pagination and section  
headings

are not available.


Yes, I seem to remember this one from before...

However, it was a while ago. You could argue it was one-off. You could  
also argue that if one document out of every
few thousand needs something extra, that should be handled by some  
waiver process. I have an existence proof of the possibility of such  
waivers...


What I hear in these discussions can get translated into a lot of it  
would be nice and

little if any it is essential that.

Changes to existing procedures tend to get driven by it is essential  
that, which is my point.

A working group saying that
the existing format restrictions are severely hindering their work  
would count for a lot here.


Regards
Marshall




- Stewart



Regards
Marshall Eubanks
CEO / AmericaFree.TV



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: RFC archival format, was: Re: More liberal draft formatting standards required

2009-07-02 Thread Pete Resnick

On 7/2/09 at 4:05 PM +0100, Stewart Bryant wrote:


Tim Bray wrote:
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van 
Beijnumiljit...@muada.com wrote:



A much better solution would be HTML, if it's sufficiently constrained.


Or, gee, we could generalize to a very constrained XML 
format.ohwait


I certainly agree that some text-based markup with reasonable tools 
for folks like Dave Mills (and others) to easily convert to a 
readable (or listenable) format is absolutely essential. As Dave put 
it, the current RFC format is unfriendly, unnecessary, possibly 
unethical and just plain wrong. I'd remove the possibly.


The showstopper has always been with figures which need to do in 
separate  files. How do you  manipulate the collection of files as a 
single object?


At least with pdf you know you have the whole thing.


We've actually got a standard for that: RFC 2387 and its brethren.

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: More liberal draft formatting standards required

2009-07-02 Thread ned+ietf
 Hi -

  From: Stefan Santesson ste...@aaa-sec.com
  To: Donald Eastlake d3e...@gmail.com; IETF Discussion Mailing List 
  ietf@ietf.org
  Sent: Wednesday, July 01, 2009 3:42 PM
  Subject: Re: More liberal draft formatting standards required
 
  How do you translate the .nroff formatted document to a readable text
  document?

 One of the advantages of nroff input is that it *is* human readable.  (To me
 it seems much easier to read than HTML, but that's not the issue here.)

That depends on the HTML. We use a stripped down XHTML format for our
documentation sources that I find far more readable than nroff source. I also
like being able to syntax check early and often - all three of the editors I
routinely use have XML syntax checkers built in.

But I find xml2rfc format even easier to read than either stripped down HTML or
nroff.

Regardless of the format you use, I believe the key is to realize that you
spend more of your time looking at the input file and not the output file, and
it pays not to be a slob. I've gotten XML source for drafts from people who
seem to get this, but I've also gotten stuff that was so awful I really could
not understand how they put up with it.

But the real difference is in the type of markup. When I'm writing I want to
focus on the content, not on presentation details. Stripped down HTML is OK in
this regard, but not nearly as good as a format that focuses on the structural
controls I need, not the presentation details I don't care about. IMO xml2rfc
doesn't go far enough in this regard.

I think the mistake many people make is in worrying about the presentation
details too soon, too often, and too much. In a very real sense that's what the
RFC Editor is *for*.

 To generate formatted output (in a variety of possible formats) the freely-
 available groff program works well.

Um, yeah, and try installing that on some only vaguely UNIXish system it hasn't
been compiled on before. Been there, tried that, ended up using ssh to run it
on a systemm where it was preinstalled.

I've also have issues with variations between different nroff processors and
different versions of macro packages. When xml2rfc became available I converted
everything to it. Vast improvement, never going back.

Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


ISOC Fellowship to the IETF - seeking applicants for IETF 76 and IETF 77

2009-07-02 Thread Mirjam Kuehne
[I am sorry if you receive this more than once.]

Dear Colleagues,

The Internet Society has announced that it is seeking applications  
for the next round of the ISOC Fellowship to the IETF  program. The  
program offers engineers from developing countries fellowships that  
fund the cost of attending an Internet Engineering Task Force (IETF)  
meeting.

As you know, the IETF is the Internet's premier standards-making  
body, responsible for the development of protocols used in IP-based  
networks. IETF participants represent an international community of  
network designers, operators, vendors, and researchers involved in  
the technical operation of the Internet and the continuing evolution  
of Internet architecture.

Fellowships will be awarded through a competitive application  
process. The Internet Society is currently accepting fellowship  
applications for the next two IETF meetings:

* IETF 76 being held in Hiroshima, Japan, 8-13 November 2009
* IETF 77 being held in Anaheim, USA, 21-26 March 2010

Up to six fellowships will be awarded for each IETF meeting.

Full details on the ISOC Fellowship to the IETF, including how to  
apply, are located on the ISOC website at :

http://www.isoc.org/educpillar/fellowship

Fellowship applications for both IETF meetings are due by 31 July 2009.

The Internet Society formally launched the ISOC Fellowship to the  
IETF program in January 2007 after successfully piloting the program  
during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Forty seven 
individuals from 29 countries have participated in the program since  
its inception.

I encourage you to pass information about this program to individuals
involved in your regional operators' groups that have a keen interest
in the Internet standardisation activities of the IETF.  You also may
consider being a reference for the applicant.

If you have questions, please do not hesiate to contact Connie Kendig
ken...@isoc.org or Mirjam Kuehne m...@isoc.org.

Kind Regards,
Mirjam Kuehne
ISOC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce