An interesting part of the current text format is that it is defined in
a very simple way: so many lines, so many columns, that's about it.
Christian,
The format has never been that simple and it has gotten increasingly complex
in recent years.
The format requirements include lines/page,
XML2RFC submission would be based on an IETF standard, and I understand
that many will find that attractive. However, for me, this is
problematic.
An interesting part of the current text format is that it is defined in
a very simple way: so many lines, so many columns, that's about it.
Compare th
Hi,
I'd like to voice my concern with the provisions of Section 10.1 of the
Trust, and respons to the Consensus Call with a voice of dissent to
consensus on the document as it currently stands.
The section of the Trust document that I have some difficulty with is
section 10.1
"10.1 Amendme
Steven M. Bellovin wrote:
That's certainly one reasonable approach. My concern was if we
decided that PDF was the right way to publish RFCs -- we'd have no
easy way to do diffs, since some people would use XML, some Word,
some OpenOffice, etc.
Put another way, I'm primarily stating a requirem
In message <[EMAIL PROTECTED]>, Bill
Fenner writes:
>On 11/24/05, Steven M. Bellovin <[EMAIL PROTECTED]> wrote:
>> If we adopt some new format, though, I think we
>> really need the ability to generate diffs of different versions of the
>> same document.
>
>The solution that comes to mind for diff
On Wed, 2005-11-23 at 20:31 -0500, John C Klensin wrote:
> Folks, not to be a stick-in-the-mud, but one of the things that
> has made the RFC Editor process attractive for authors is that
> it is possible to design and use the right format for a
> particular presentation. Sometimes that means "in
On 11/24/05, Steven M. Bellovin <[EMAIL PROTECTED]> wrote:
> If we adopt some new format, though, I think we
> really need the ability to generate diffs of different versions of the
> same document.
The solution that comes to mind for diffs is to format the old version
(to text), format the new ve
At the other hand, I would want everybody to realize that if we say:
..., but pure text is still welcome, with hand-conversion
by the editor staff.
that that means a SERIOUS cost.
right. that is why we should have moved to an automated submission process
long ago.
the issue, now
But one of the reasons for EARLY submission deadline is to ensure that
the IETF participants actually get some time to READ/STUDY the documents
that need f2f time in IETF WG meetings!
When TCP was improved enough so that it could saturate a ethernet (jumping
from a max of 2Mbps to more than
In message <[EMAIL PROTECTED]
om>, "Wijnen, Bert (Bert)" writes:
>>
>
>Let me repeat, that as far as I know, the RFC editor does NOT have
>.xml versions of the FINAL RFC. They always end up generating .nroff
>files and do some tailoring/editing to the .nroff before the final
>RFC gets produced (f
Wijnen, Bert (Bert) wrote:
But one of the reasons for EARLY submission deadline is to ensure that
the IETF participants actually get some time to READ/STUDY the documents
that need f2f time in IETF WG meetings!
Indeed. The idea is that since XML-RFC-formatted drafts can be vetted
automatical
> > - Making XML-RFC versions of existing or new RFCs available
> > to the public.
>
> absolutely!
>
I see support of this a few times (and that includes me).
I think that if you (we) all really mean this,
then I think it would be good to see if you can get it accepted
as an IETF (consensus)
W.r.t.
> > - We can say that it's time to require XML2RFC for all drafts.
>
> there is a variant of this that i think i like:
>
> do not impose this switch onto those submitting, but change
> the formatting language used by the rfc editor to be xml2rfc.
>
> so, submissions in xml2rfc are highly
Dave Crocker wrote:
> This looks like quite a good list. The only thing I would add is an
> interactive submission tool that validates the xml2rfc document being
> submitted.
>
> Rather than explicitly penalize the text submitters with an earlier date,
> I'd suggest providing a bonus extension
14 matches
Mail list logo
