On Wed, Jan 11, 2006 at 01:02:55AM +0100,
Frank Ellermann [EMAIL PROTECTED] wrote
a message of 11 lines which said:
this code should work as it is forever for everybody who wants it
to work.
Yes, the good point about Graphviz is that it is readable even if you
do not know / have the
Eric,
...
Moreover, I believe there is evidence to this effect, as
pointed out previously, in the fact that at least one RFC is
essentially only available in PS and PDF format.
That is an RFC that predates not only RFC 2026 but also its
predecessors, RFC 1602 and 1310. So it doesn't
Randy.Dunlap wrote:
On Tue, 10 Jan 2006, Brian E Carpenter wrote:
...
What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code. You can't
do that with plain ASCII.
You can do that with meta-data encoded in
Likewise, often I see folks bring something that needs to be solved
to the IETF. This can generate lots of interest, especially if the
person with the problem is a customer. However, that still doesn't
mean the solution space is in the realm of the IETF.
It seems to me that if the problem is
*
* Under those conditions, our precedents are that you can probably
* convince the WG/WGchairs/ADs, and eventually the RFC Editor,
* that a PDF document containing a picture of the Mona Lisa and an
* ASCII document with
*
* _-
* / \
*
* The draft has expired so I need to point to an external version. This draft
* which is looking at the properties of a routing network under conditions of
* failure would have been much clearer if it could have used mathematical
* notation rather than ASCIIised equations
*
*
* Scott,
*
* How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
* of readable equations in ASCII? I my experience, normative protocol
* technical specifications rarely need equations much more complex than
* these examples. The only significant exception
* I would like to enable automated testing of ABNF.
Note that the RFC Editor has been running ABNF through an
automated checker, for quite a long time. We find errors.
RFC Editor/bb
___
Ietf mailing list
Ietf@ietf.org
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
*The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
*
Your knowledge is apparently incomplete. The RFC
On Jan 10, 2006, at 5:47 PM, Dave Crocker wrote:
Lucy, I suspect that they merely were making a spelling error,
since I'm sure they were referring to folk who are truly essential,
and therefore qualify as linch pins...
I have never heard of a linching party. RFCs filled with base64
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
[EMAIL PROTECTED] wrote:
* The RFC editor has some problems which have not, to my
knowledge, * been enumerated.
*
Your knowledge is apparently incomplete. The RFC Editor has
been actively experimenting with using xml2rfc
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
*
Your knowledge is apparently incomplete. The RFC
on 2006-01-11 22:02 Bob Braden said the following:
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my knowledge,
* been enumerated.
There is not currently a version of xml2rfc that meets our
needs.
I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing
list, citing xml2rfc's deficiencies.
That makes it difficult to get those deficiencies fixed.
Please, please, please. Post those deficiencies to
on 2006-01-11 23:00 Ned Freed said the following:
* From: Brian Rosen [EMAIL PROTECTED]
* To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org
* Date: Tue, 10 Jan 2006 20:13:35 -0500
* The RFC editor has some problems which have not, to my
knowledge,
* been
There is not currently a version of xml2rfc that meets our
needs.
I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing
list, citing xml2rfc's deficiencies.
That makes it difficult to get those deficiencies fixed.
Please, please, please. Post those deficiencies
when the RFC does use
xml2rfc for
most of the editing process getting back a revised XML spec from the RFC
Editor
that has all the changes made prior to the nroff step would be a HUGE
improvement. The time needed to retrofit all the RFC Editor changes into
the
XML is nonnegligable - I wish I
On Jan 11, 2006, at 1:52 PM, John C Klensin wrote:
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
[EMAIL PROTECTED] wrote:
Your knowledge is apparently incomplete. The RFC Editor has been
actively experimenting with using xml2rfc for publication, and we
have been passing our
Do we know where the meeting will be yet? I see that registration was
supposed to start today.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for
Dummies,
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
I dropped the toothpaste, said Tom,
A new IETF working group has been formed in the Security Area.
For additional information, please contact the Area Directors
or the WG Chairs.
+++
Domain Keys Identified Mail (dkim)
==
Current Status: Active Working Group
CHAIRS:
Stephen Farrell [EMAIL
A modified charter has been submitted for the ADSL MIB (adslmib) working
group in the Operations and Management Area of the IETF. The IESG has not
made any determination as yet. The modified charter is provided below for
informational purposes only. Please send your comments to the IESG
A new IETF working group has been formed in the Internet Area. For
additional information, please contact the Area Directors or the WG Chairs.
+++
Network-based Localized Mobility Management (netlmm)
=
Current Status: Active Working Group
A new Request for Comments is now available in online RFC libraries.
RFC 4186
Title: Extensible Authentication Protocol Method for
Global System for Mobile Communications (GSM)
Subscriber Identity Modules (EAP-SIM)
Author(s):
A new Request for Comments is now available in online RFC libraries.
RFC 4355
Title: IANA Registration for Enumservices email, fax,
mms, ems, and sms
Author(s): R. Brandner, L. Conroy, R. Stastny
Status: Standards Track
A new Request for Comments is now available in online RFC libraries.
RFC 4343
Title: Domain Name System (DNS) Case Insensitivity
Clarification
Author(s): D. Eastlake 3rd
Status: Standards Track
Date: January 2006
A new Request for Comments is now available in online RFC libraries.
RFC 4187
Title: Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement
(EAP-AKA)
Author(s): J. Arkko, H. Haverinen
A new Request for Comments is now available in online RFC libraries.
RFC 4348
Title: Real-Time Transport Protocol (RTP) Payload Format
for the Variable-Rate Multimode Wideband (VMR-WB)
Audio Codec
Author(s): S. Ahmadi
A new Request for Comments is now available in online RFC libraries.
RFC 4351
Title: Real-Time Transport Protocol (RTP) Payload for
Text Conversation Interleaved in an Audio Stream
Author(s): G. Hellstrom, P. Jones
Status: Historic
A new Request for Comments is now available in online RFC libraries.
RFC 4356
Title: Mapping Between the Multimedia Messaging Service
(MMS) and Internet Mail
Author(s): R. Gellens
Status: Standards Track
Date: January
29 matches
Mail list logo
