Subject: [Tools-discuss] Comments on draft-ietf-tools-draft-submission-08.txt

From: Matthew Elvey <[email-masked]>
Date: Tue, 10 May 2005 14:25:46 -0700

Sorry for the late comments, but it seems another round is in process 
anyway...apologies for any duplicates.

Having given this a couple reads, most of my concerns were addressed.  
Compression is IMO a silly feature, but its implementation is optional, 
so that's OK. (And I wonder if HTTP 1.1 doesn't support compressed POSTs.)

I  still wonder if anyone has done a survey (formal or anecdotal 
guesstimate) to determine what format drafts are created in (i.e. source 
format) these days. Even though the RFC Editors reportedly* don't use  
nroff/troff any more, it seems quite popular, and justifiably 
preferred** by some users who've tried both.  I suppose they can 
continue to submit drafts the old way, if they're just a vocal small 
minority.

*http://www1.ietf.org/mail-archive/web/tools-discuss/current/msg00280.html
**http://www1.ietf.org/mail-archive/web/tools-discuss/current/msg00301.html

Does the draft take into account that it is probably much easier for the 
Secretariat to convert a document from one format to another (especially 
given appropriate instructions or better yet standard procedure 
regarding use of existing tools) than it is to compare two documents to 
confirm that they are not substantially different?  Or am I mistaken?

Should one of the validation steps be approval (a good score from) an 
anti-spam system such as SpamAssassin?  I guess this can be a feature 
added later if it turns out it's needed.  I'd bet it will be.

--
Matthew

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2005 12:30:27 +0200

Yes, we did a rough survey, and XML was the preferred format by
a substantial majority, with a decent minority still using nroff,
and most of the rest assumed to be using Word.

BTW team, when can I expect a -09 draft to submit to the IESG?
Progress would be good.

    Brian

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 11 May 2005 08:51:15 -0600

> confirm that they are not substantially different?  Or am I mistaken?

Secretariat is not and will not be manipulating submitted drafts, including
format conversion. While it may be easy to convert from one format into
another (and the draft requires such conversion from XML sources), the
danger of autoconversion is that the result does not match the author
expectation.

For example, whenever a new version of xml2rfc is out, there
is often at least one complaint that the new plain text output differs
 from the old plain text output, and the difference breaks something
important in the author's draft.

I believe it is better to have in imperfect auto-comparison (and risk
a few rogue drafts to be published) than an imperfect conversion
(and risk many corrupted drafts to be published). The current Toolset
requirements reflect that belief and give the submitter a choice:
let the Toolset to auto-convert from submitted XML to plain text or
let the Toolset auto-compare submitted XML and submitted plain text.
Personally, I think I will use the latter mode more often.

> added later if it turns out it's needed.  I'd bet it will be.

I do not see why an email draft submission that SpamAssassin marks as
spam but that also passes all IETF-specific checks should be rejected.
For example, I doubt spam will come with IETF-compliant IPR disclosures
any time soon.

However, I agree that adding spam or other filters to the email interface
would be possible if such filters are needed.

Thank you,

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Wed, 11 May 2005 16:00:16 -0700

On 5/10/05, Matthew Elvey <[email-masked]> wrote:
> Even though the RFC Editors reportedly* don't use
> nroff/troff any more

The antecedent of "it" in the email is not "nroff sources" but is "my
nroff sources".  The RFC Editor still uses nroff, they just
(reportedly) don't use nroff sources that people submit (mostly
because people like to use macros and the RFC Editor doesn't trust
macros as different versions of the macros can create different
results, and they want to be able to recreate the exact bits of a
given RFC).

  Bill