Subject: [Tools-team] Re: draft-ietf-tools-draft-submission-04.txt

From: stanislav shalunov <[email-masked]>
Date: 20 Oct 2004 01:45:32 -0400

Addendum: It wasn't clear to me if the email interface would take a
(single-format) submission that came in the body of a non-MIME email
message.  (I think it definitely should.)

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed upside down.

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

---

From: stanislav shalunov <[email-masked]>
Date: 20 Oct 2004 01:38:10 -0400

Alex,

Here are some comments on the draft.

A very general comment: I suspect that since we're all aware of the
context, it's difficult for us to understand what would baffle an
outside developer.  There's a lot of jargon that we rely on, and it
would be easy for us to miss defining a few terms.  Later on, when we
agree on the substance and fill in all the blanks, we should ask some
technical person who has never participated in the IETF (or perhaps a
newcomer) to review the document.

# 1.  Introduction
#    unnecessary load on the IETF Secretariat.  The IETF TOOLs team

What is the correct capitalization of ``Tools''?  It's not an
abbreviation, so it should not be in caps; it's not a trademark, so it
should not be in small caps.  It's a proper name (in this particular
context), so it should be capitalized: Tools.

# 3.  Scope
# 
#    The Draft Submission Toolset discussed in this document is about
#    getting a single new revision of an Internet-Draft from an IETF
#    participant to the IETF draft repository.

Is initial submission a revision?  How about s/revision/version/?

#    submitter: A human or software initiating submission of an

``Human or software agent'' or ``A human or a piece of software''

#       Internet-Draft for validation or posting.

                      ^ version?  Or are you really talking about the
submitter of -00 (which is how this reads to me)?  If the latter,
maybe ``original submitter''?

#    authorized submitter: A lawful submitter authenticated by the Toolset
#       as such.

A submitter authenticated by the Toolset as a lawful submitter.

#    draft version: [[XXX68: Define and check whether version or revision
#       should be used.  --Alex]]

I suggest ``version,'' as ``revision'' strongly connotes the existence
of an original that is being revised.

Suggested definition:

A string consisting of digits and representing a non-negative integer
in decimal; single-digit numbers are padded with a single zero on the
left.  Examples of valid draft versions: 00, 03, 12, 911.  Examples of
invalid draft versions: 0, -1, 001.

#    draft format: Any draft source or presentation format, including
#       original and preprocessed XML, original or generated plain text as
#       well as PDF, Postscript, and HTML formats.  [[XXX67: change "draft
#       version" to "draft format" where appropriate.  --Alex]]

So, we disallow the posting of Microsoft Word files?  I hear some
people use a Word template to create I-Ds.  Note that while Word is
proprietary, so are PostScript and PDF.

What about nroff?

(I also thought that PostScript was BiCapitalized.)

I would also add DVI, if we allow PDF.  It's proprietary, too, but at
least very stable.

#    primary draft format: The first available draft format from the
#       following list: plain text, Postscript, PDF, XML.

Exchange PostScript and PDF?  PDF is more common today (and is likely
to remain in the future, unless PDF and PostScript fall into equal
disuse).

#    immediately: without human interaction or artificial software delays.

and typically within seconds?

#    To get an Internet-Draft posted on IETF web site, an IETF participant
                                       ^ the?

#    e-mails draft text to the IETF Secretariat, along with an informal
      ^ I'd strike the hyphen, but that's just me (and the Oxford guys).

#    Collectively, IETF participants submit thousands of Internet-Drafts
#    per year (in the year 2000, about three thousand drafts were
#    submitted; 2002: 5K; 2004: 7K).

Lowercase `k'.  A reference?  (``According to private communication
from the Secretariat''?)

#    posting delays.  For example, many draft subversions are
                                              ^^^^^^^^^^^

minor versions?  sub-versions?  revisions between officially posted
versions?

#    and submitters are not notified of any violations.  As a result, IESG
#    and RFC Editor may have to spend resources (and delay standard
                                                           ^^^^^^^^ strike
#    approval) resolving violations with draft authors.  Often, these
#    violations can be detected automatically and would have been fixed by
#    draft authors if authors knew about them before requesting to publish
                     ^ the
#    the draft as a standard.
               ^^^^^^^^^^^^^ strike

[We're talking about all drafts, not just standards-track, aren't we?]

#    Initial submissions of WG drafts require WG Chair approval, which
                            ^^^^^^^^^

Should this be defined in the definitions section?

#    However, future automation may result in a different trade off.
                                                               -

#    Upload page: Interface to copy draft from submitters computer into
                                                       ^ apostrophe

#    Check page: Displays draft interpretation and validation results
#       (Section 9).  Draft preview may also be given on this page.  After
#       reviewing draft interpretation and validation results, the
#       submitter has four basic choices (a) auto-post draft "as is" now;
#       (b) make manual corrections and submit the draft to Secretariat
#       for manual posting later; (c) cancel submission; or (d) do
#       nothing.  The automated posting option may not be available for
#       drafts with validation errors.

What's the difference between ``do nothing'' and ``cancel'' from a
user's point of view?

# 
#                        /---> Post Now
#                       /
#    Upload --> Check -+-----> Adjust ---> Send to Secretariat
#                       \
#                        \---> Cancel

If we're going to have a flow-chart, it should be done as such, with a
diamond (``Is the draft valid and the user authorized to post?'')
before ``Post''.  (Or the chart could just be removed.)

#    If the submitter does not select any explicit action for 1 hour, then
#    the submission is considered abandoned, and all corresponding state
#    may be deleted by garbage collection (R66).  The staging area
#    maintenance algorithms must be robust in the presence of DoS attacks
#    attempting to overwhelm the area with fake submissions in various
#    stages (R67).

I think R67 needs to be clarified.  What's the property that we're
looking for?  Can it be satisfied?  Is it enough?

Here are some straw men:

An attacker who controls only a small number of IP addresses may not
be allowed to exhaust the system's storage space so that service is
denied to other users.  [Not enough: IPv6 lets you have plenty of IP
addresses.]

An attacker may not be allowed to exhaust the system's storage space
so that service is denied to other users.  [Not clear how this could
be satisfied by an implementation---no restrictions are placed on the
attacker, so he might have the ability to send lots of draft
submissions that look just like legitimate ones.  Also, not enough as
the attacker might saturate some other resource.]

#    The "web pages" this text is referring to are distinct dialogs, that
#    may be visible to the submitter under the same or different URL, and
#    supported by a single or several CGI scripts (or even applets).

Are we talking client-side Java applets here?  I'd hate it if the
interface relied on anything that fancy and that unstable.

#    To upload the draft, the submitter goes to a well-known page on the
#    IETF web site (R1).  There, the draft text can be uploaded using an
#    HTML file input form.
               ^^^^^ upload?  This sounds a lot like a text input box
                              to me.

#    The Toolset should have a Validation page, identical to the Upload
                               ^^^^^^^^^^^^^^^ linked from the
                               well-known upload page?

#    be be posted (R76); they would need to be uploaded via Upload page
     ^^^^^ strike one ``be''

#    for that, and the validation results page should explain that (R77).
#    This page, hosted at a well-known location, would be useful for tools

Should there only be one well-known location to identify?

Should validation be able to take drafts from URLs?  (Same for
posting.)

#    The Check action preprocesses XML draft source (if any), generates
#    plain text format (if needed), stores submitted draft (all formats)
#    in the staging area, and then extracts meta-data and validates each
#    format (R6).

It's not clear to me if you intended the requirements to make it
possible to submit XML instead of plain text or in addition to plain
text.  ``if needed'' -- when is it needed?  I found R70 later.  Maybe
a forward pointer?

#    It is an error to submit a draft which has neither plain text nor XML
#    sources format (R68).  XML source is acceptable without accompanying
#    plain text only if the Toolset successfully generates a draft in
#    plain text format from the XML source, as a part of the processing
#    step (R69).

What happens if generated plain text and submitted plain text do not
match?

#    If XML sources are available, the Toolset generates HTML draft format
#    (R112).

What is the purpose of this?  We currently have a stable format for
I-Ds.  Introducing HTML I-Ds will make them preferred for a subset of
participants, and then we'll be looking at different documents (a
complaint of an HTML reader about the formatting of a diagram might
make no sense to a plain text reader and vice versa).

#    The Check action stores all submitted formats of the draft in a
#    staging area dedicated to the Toolset (R12).  If, after garbage
#    collection, the staging area is full (i.e., the total used size
#    reached configured maximum capacity), the submitter and the
#    Secretariat are notified of a fatal error (R13).

How does this dovetail with robustness against DoS?

#    Each stored draft format is interpreted to extract draft meta-data
#    (R14).

Are you serious about extracting anything useful from PDF?

#    If a given format is interpreted and meta-data extraction
#    fails, the Toolset records an error (R15).

What happens then?

#    WG ID: IETF working group identifier.  WG value is empty for
#       individual drafts not meant to be work items of a known WG and for
#       non-IETF drafts.  For example, "tools" in
#       "draft-ietf-tools-draft-submission-13" and "opes" in
#       "draft-rousskov-opes-ocp-00" are both WG IDs.

So, what about draft-rousskov-draft-submission-13?  This needs to be
defined so that it can be understood by an outside implementor who's
never seen an I-D.

#    WG flag: True for IETF WG drafts and false for all other drafts.  For
#       example, "true" for "draft-ietf-tools-draft-submission-13".

Does this count the number of dashes in a filename or are we talking
about something else.

#    authors: A list of all draft authors.  For each author, their first
#       name, last name, and e-mail are extracted.

First name or initial?  Should it look at the addresses where a full
name might be found even if only an initial is on the title page?

#    submission date: Draft submission date.

Should this be extracted from the draft or from the clock?

#    If e-mail of an author cannot be extracted, the Toolset reports a
#    warning (R95).

I think this should be an error to prevent disputes.  If someone wants
to include me as a co-author without my consent and puts
[email-masked] as my email address, I can later point to that
address and claim it as suggestion of malicious intent.  (Eliciting a
mandatory response from co-authors would turn the suggestion into
proof.)  If an address is lacking it's more difficult for me to
convince others that I really did not give consent to posting.

#    E-mails

Email addresses (uncountable).

#    XML source needs to be preprocessed to resolve XML processor
#    instructions to include references.  The action needs to store all
#    draft formats so that successfully validated drafts can later be
#    auto-posted at submitter request.

Is this not included in duplicate?

#    mis-detected violations).  These explanations may speedup
                                                       speed up

#    posting decision and may help help Secretariat to improve Toolset
                              ^^^^^^^^^

#    2.  A draft must be submitted by an authorized submitter (R19).
#        [[XXX13: move this lower, we do not know the submitter at this
#        stage --Alex]][[XXX14: Don't forget the co-author, changed
#        editor, and drafts being posted anonymously (secretariat needs to
#        know who submitter is, but name doesn't necessarily appear on
#        draft) --Harald]]

Also, third-party submissions (e.g., a WG chair submitting a draft not
in his name).  Would this be allowed?

#    6.  Posting this draft must not result in any Denial of Service
#        attack threshold to be crossed (R97).  "Individual" DoS threshold
#        for a given draft is 3 revisions per day.

Is this for a given draft name?  This is no DoS protection, as an
attacker could vary the name.  (Legitimate users might be affected in
rare cases.)

#       "Global" DoS
#        thresholds for all drafts are 500 submissions and 1GByte worth of
#        data in past 24 hours.  Other thresholds may be introduced and
#        these initial thresholds may be adjusted as necessary.  The
#        thresholds are likely to become more smart/dynamic with
#        experience.

Shutting down under excessive load as a DoS protection mechanism?

#    Hint: Bandwidth available for submissions may need to be throttled to
#    make reaching the daily size quota (with malicious intent) difficult.

Then it becomes easier to saturate the link capacity resource.  Even a
tiny 1Mb/s gives 10GB/day.  Do you really want it throttled to 100kb/s?

#    Violating any of the following requirements does not prevent the
#    submitter to auto-post the draft (R24).
               ^^^^^^^^^^^^ from auto-posting

#    2.  New draft revisions are expected (R21).  For example, revision 00
#        of an individual draft is always expected, while posting a
#        revision of a draft already under IESG review should generate a
#        warning.

This should be an error, not a warning.  If a draft was ever posted
with a given version number, and some people grabbed it, replacing it
for the future is Bad.

Also, the new version needs to be greater than all the existing ones.

Skipping a version number should be a warning (might be legitimately
done if the IETF I-D submission system was down for a while and
intermediate versions were posted informally).

#    Extracted meta-data items that were not successfully extracted or
#    that failed validation checks must be marked specially (rather than
#    silently omitted) (R26).

I don't understand how does one extract something unsuccessfully and
have it (presumably as a non-empty string).

#    The submitter can also enter external meta-data (Section 9.1), which
#    is required for automated posting of the draft (R28).

It seems that the only required item in the external meta-data section
is submitter email address.  But if that can't be extracted, the draft
goes into manual service queue anyway.  What does R28 then mean?

#    page.  Displaying draft image from the first line up to the last line
                       ^^^^^^^^^^^  An actual image like a PNG file?

#    For draft updates, the Check page reports the the time and the
                                               ^^^^^^^
#    submitter of the last update (R83).  This information is especially
#    useful when multiple authors are working on the same draft.  The page
#    also provides a link to generate a diff against the last posted
#    version (R84).

Talk more about diff format perhaps?

# 10.  Post Now action
# 
#    The Post Now action checks that the draft has been successfully
#    validated (R34), validates external meta-data (including submitter
#    e-mail) (R35),

How do you validate submitter email if it's not from the draft?

I'd say if it's not the first author's email (or perhaps some
authorized user like a WG chair, an AD, etc.), it should be queued for
manual service.

#    The Toolset provides both e-mail and web interfaces for confirming
#    e-mail access (R99).  Hint: To check submitter's access to e-mail the
#    tool can e-mail a hard-to-guess cookie or token to the submitter's
#    address.  To continue with the submission, the submitter is requested
#    to either go to the token-holding URL or respond the the e-mail.

Or paste the cookie into a form field (which I would personally prefer
as a user).

#    The Receipt page should give the submitter a URI or another
#    identifier that can be used by Secretariat for manual troubleshooting
#    of the submission (R63).  The identifier should be perpetual (R64)
#    even though the associated details are likely to be eventually lost
#    (e.g., draft submission data and logs are deleted from the staging
#    area as a part of the garbage collection routine).

What would happen if I enter this perpetual URI into the browser after
everything is deleted and would it be any different if I changed one
digit in the session-id?

#    validation errors were found (R51).  The Manual Check page should
#    still contain all the errors and warnings seen by ordinary submitters
                                              ^ identical to those

#    Using manual processing may result in significant posting delays.
#    Generated submission receipts or notifications ought to give the
#    submitter an expected processing time estimate (R53).

How can the tool do this?

#    The e-mail interface accepts a draft as a set of e-mail attachment(s)
#    (one per draft format) (R56), uses sender's e-mail address to select
#    submitter's identity (R57), checks the submission (R58), and posts
#    the draft if the check is successful (R59).  The submitter should be
#    notified of the outcome of the draft submission via e-mail (R60).
#    Other requirements for web interface (including requirements on draft
#    validation, submitter authentication, draft posting, and
#    notification) apply to e-mail interface.

It might help if you added some text to the effect of the following:

Therefore, a submission might consist of the following messages, if
PGP or S/MIME is not used for authentication: (1) [from the submitter]
the draft; (2) [from the Toolset] a challenge to verify access to
email address; (3) [from the submitter] a response to the challenge;
(4) [from the Toolset] a check page with possible warnings and a
receipt or a check page with errors.

This message is designed to be viewed in boustrophedon.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 21 Oct 2004 21:36:27 +0200

> proprietary, so are PostScript and PDF.

Postscript and PDF have published definitions.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 21 Oct 2004 16:00:18 -0700

For long-term archiving of published specifications, it
might be useful to look at the PDF/A profile,
once it's finalized and there are tools for checking:

   http://www.aiim.org/pdfa

Basically, PDF/A is a restricted profile of PDF
that is suitable for long-term archives. It's
expected to be an ISO standard in 2005.

Larry

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 22 Oct 2004 00:43:39 -0600 (MDT)

Stas,

 	Appreciate the comments. Lots of good ideas and bug reports! 
Fortunately, many bugs have been already fixed, or I would not be able 
to finish addressing your comments within 48 hours! Unfortunately, I 
could not resolve all issues without more information/discussions, and 
we will need another round to finish this beast.

 	I have requested posting of version 05 (CCed to this list). 
Please use that version from now on. I will send version 06 for 
posting once we reach consensus on the issues that you found and I 
could not fix. FWIW, this will give me a chance to finish assigning 
implementation priorities and finally read the draft as a whole.

 	Below, I will only comment on issues that may require further 
discussion. AFAIK, all other issues are resolved in version 05 of the 
draft, based on your suggestions, questions, or concerns. Please let 
me know if I missed anything.

> newcomer) to review the document.

In general, I think we should expect any developer to be familiar with 
IETF jargon and ask questions if something is not clear. We will never 
finish otherwise because we are operating in an environment where many 
core IETF "things" are not clearly defined anywhere. A draft about a 
simple tool cannot and should not try to fix that problem. Personally, I 
feel that the amount of details outside of the Toolset primary focus is 
already at a dangerously high level.

Also note that it is probably the Secretariat or some internal IETF 
team that will build the Toolset. In either case, the implementer and 
maintainer will be familiar with IETF jargon and process.

> A submitter authenticated by the Toolset as a lawful submitter.

That would still be imprecise because the Toolset authenticates the 
submitter (not whether the submitter is lawful) after checking that 
the un-authenticated submitter is lawful. For example, if I, using 
your e-mail in the draft, claim to be you submitting a 00 version of 
your draft, the Toolset has not choice but to treat me as a lawful 
submitter. However, authentication part would fail because I cannot 
read your e-mail.

Currently, the draft reads:

 	A lawful submitter authenticated by the Toolset.
 	Authentication is initially limited to verifying submitter
 	access to submitter's e-mail address.

> proprietary, so are PostScript and PDF.

Not sure what you mean by "proprietary". While I am not fond of any of 
the above formats, PostScript and PDF are at least publicly documented 
standards while Word, AFAIK, is not. If it were my choice, I would 
only accept plain text and HTML (with images), but I am not going to 
fight that battle. XML sources aside, we are simply relying on the 
existing IETF policy for draft formats.

> What about nroff?
...
> I would also add DVI, if we allow PDF.  It's proprietary, too, but 
> at least very stable.

Similar arguments apply. My suggestion would be to introduce no new 
formats at this time (besides XML). With so many formats already 
allowed it should be easy to add more later, if needed (i.e., if there 
is real demand for more formats).

> Lowercase `k'.

Why?

> Should this be defined in the definitions section?

I would rather not, but will do so if anybody else wants more 
definitions.

> before ``Post''.  (Or the chart could just be removed.)

Here I disagree. This is just a handy, imprecise summary/illustration, 
not a formal flow chart. Besides the intent, the condition is even 
more complex than you specified. For example, a submitter may pick the 
manual route even if the draft is valid (perhaps there is a bug in the 
Post Now action that the submitter knows about).

I added the word "informal" to the diagram description.

> the attacker might saturate some other resource.]

I think it is fine to deny [any] service when under DoS. We are not 
talking about medical services here. Here is the current wording:

     The staging area maintenance algorithms must keep the area in a
     consistent, correct state in the presence of DoS attacks attempting to
     overwhelm the area with fake submissions in various stages (R67). Hint:
     denial of service to legitimate users is acceptable under DoS attack
     conditions, but corruption of storage area is not.

Is that better? At the very least it is easy to implement/satisfy, IMO.

> Should validation be able to take drafts from URLs?  (Same for

I would worry that fetching arbitrary URLs would make the Toolset a 
client or even a proxy with no access controls. I think it is safer to 
operate in a receive-only mode, without any fetching of external data. 
What do others think? Are there many real use cases for 
post-a-draft-at-this-URL feature?

> make no sense to a plain text reader and vice versa).

The purpose of this is to give participants an alternative rendering 
that is much easier to navigate than plain text. While minor 
differences are unavoidable, any significant "makes no sense" comment 
would imply a bug in HTML generation tool. This also gives us an 
opportunity to start a [very] slow migration towards a 
generally-better default format without much fighting with folks who 
still prefer plain text.

We are not accepting HTML drafts. We just render drafts with XML 
sources as plain text and HTML...

I consider HTML rendering a useful experiment, but do not insist on 
it. It just seems silly to have XML sources and not offer an HTML 
rendering format that many folks prefer.

> How does this dovetail with robustness against DoS?

Sorry, not sure what you mean here. I do not think the Toolset should 
try to fight a DoS attack (see below for details).

> Are you serious about extracting anything useful from PDF?

Sure, as a long-term goal. FWIW, I extract limited text from PDFs 
(using a pdftotxt tool) quite often. I suspect we can, eventually, 
have some kind of PDF templates or formats that would make this 
easier. Until PDF extraction works, PDF-only drafts cannot be 
auto-posted, of course. If PDF extraction is impossible, we should not 
accept PDF drafts at all, IMO.

> #    fails, the Toolset records an error (R15).

Please see:
# If any error is found, automated posting becomes impossible (R113), 
# but ...

> defined so that it can be understood by an outside implementor who's

I agree, but precise definition would take quite a lot of space and is 
not really in scope of this draft. Can we assume that an implementer 
have seen drafts before or, at least, can educate himself?

> Does this count the number of dashes in a filename or are we talking

As you know, the rules to identify what is a WG draft are quite 
complex (I think Change log has some comments about this). Here, we 
are not defining these rules. We expect the implementor to satisfy the 
requirement. We do not care how they compute the value. We only care 
that the value is correct. Is that a good approach? Depends who the 
implementer is, I guess. We also give some hints on what to look for.

> Should this be extracted from the draft or from the clock?

Definitely from the draft. See R16. Using clock would lead to a 
mismatch between draft meta-data and draft text. Note, however, that 
the Toolset should validate what it extracted so that draft version 
creation and expiration dates satisfy IETF rules and make sense.

> convince others that I really did not give consent to posting.

As a non-submitter, you did _not_ give consent to posting, but you have 
a point that omitting e-mail is easier than specifying a fake one. 
However, a malicious user can simply make a "typo" in your e-mail 
address.

What do others think? Should we require e-mail addresses for all 
authors? We are only talking about drafts that are meant to be 
auto-posted here...

> attacker could vary the name.  (Legitimate users might be affected in

By "This is no DoS protection", do you mean "there are ways around this 
DoS protection"? It seems to me that the protection makes sense (e.g., 
there will be folks that monitor a given draft and they should be 
protected from receiving 500 e-mails).

> Shutting down under excessive load as a DoS protection mechanism?

Not sure what you mean by "DoS protection mechanism", but I think that 
simply "shutting down until humans can look at it" is the Right Thing to 
do when DoS is detected, *in this particular environment*. This approach 
is simple, robust, and effective. Again, IETF would not suffer much if
automated submission service stops functioning for a little while.

As we gain more experience, smarter schemes may become necessary. Or 
they may not...

> with a given version number, and some people grabbed it, replacing it

And sometimes it is good because the people that grabbed it asked for a 
new revision. And sometimes while it may seem like they asked for a new 
revision (e.g., based on ID tracker output), they actually did not (I 
have an OPES draft in that state right now).

We received many comments about R21 and the current wording seems to be 
the best we can do (IMO), given the multitude of possible situations. 
The Toolset will simply not be able to enforce the Right Behavior here 
(but will warn about possible problems).

> Also, the new version needs to be greater than all the existing ones.

That's an absolute requirement R22.

> intermediate versions were posted informally).

I disagree. Version numbers are too critical for many pieces of 
infrastructure to allow gaps. Informal postings can use informal 
notation like "-03b2".

>                       ^^^^^^^^^^^  An actual image like a PNG file?

No, just the first lines, but I cannot come up with a better word than 
"draft image" because if I say "draft text" some may think that draft 
header is not included... Help?

> Talk more about diff format perhaps?

Diff format(s) are out of this draft scope, IMO.

> authorized user like a WG chair, an AD, etc.), it should be queued for

Please see R19, and R119 - R122 in the new draft version.

> How can the tool do this?

The Secretariat already does that in their current auto-notification, 
IIRC. The estimate does not have to be precise.

Please discuss the remaining issues above and see if there are any 
show-stoppers in version 05 of the draft.

Thanks a lot,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 22 Oct 2004 00:44:34 -0600 (MDT)

> message.  (I think it definitely should.)

This used to be XXX37 and it was resolved (against your wishes) in 
version 04. Here is a quote from the Change log in Appendix C:

 	Resolved XXX37: E-mail submissions must use attachments, even
         if there is only one draft format. This may help to keep the
         Toolset simple (no smarts needed to isolate true draft text from
         notes in the beginning of the e-mail and signatures).

Why do you think this feature is desirable? What do others think?

Thank you,

Alex.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Oct 2004 09:19:37 +0200

--On 22. oktober 2004 00:43 -0600 Alex Rousskov 
<[email-masked]> wrote:

>  	I have requested posting of version 05 (CCed to this list). Please use
> that version from now on. I will send version 06 for posting once we
> reach consensus on the issues that you found and I could not fix. FWIW,
> this will give me a chance to finish assigning implementation priorities
> and finally read the draft as a whole.

Note that pre-IETF submission of I-Ds closes on Monday morning.

Did you want to have time on the agenda for the tools team in San Diego? So 
far I have neither booked a general area meeting nor a tools team BOF.

         Harald

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 22 Oct 2004 10:01:15 +0200

Harald Tveit Alvestrand wrote:
>> Please use
> Did you want to have time on the agenda for the tools team in San Diego? 
> So far I have neither booked a general area meeting nor a tools team BOF.

Yes, we had been thinking of a slot in the general area meeting.
I hadn't thought of the possibility of doing a BOF - guess I'm thinking
BOF = kick off new work, which is a bit too limited :-)

Either would work.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 22 Oct 2004 10:04:03 +0200

> Why do you think this feature is desirable? What do others think?

Going for simplicity first, I think it is fine to require that the
draft is in an attachment.  However, you might add a requirement that
an email submission with no attachment should generate a response
indicating that an attachment (with the draft) was expected but not
found.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 22 Oct 2004 10:25:06 +0200

Hi Alex, Stas,

     Stas: Lots of good comments.  I comment only on those below
which Alex didn't already incorporate.

	Henrik

Alex Rousskov wrote:
>     I have requested posting of version 05 (CCed to this list). Please 
> use that version from now on. I will send version 06 for posting once we 

Sounds good

> draft, based on your suggestions, questions, or concerns. Please let me 
> know if I missed anything.
> 
> IETF jargon and ask questions if something is not clear. 
>
> We will never 
> Also note that it is probably the Secretariat or some internal IETF team 
> that will build the Toolset. In either case, the implementer and 

Agreed.  The developer will in all likelihood be the Secretariat 
Developer, Mike, who has been working on other tools, including
building the ID-Tracker, so he may know more than us about some
aspects of the IETF ...

> submitter (not whether the submitter is lawful) after checking that the 
> un-authenticated submitter is lawful. For example, if I, using your 
> e-mail in the draft, claim to be you submitting a 00 version of your 
> draft, the Toolset has not choice but to treat me as a lawful submitter. 
> However, authentication part would fail because I cannot read your e-mail.
>

Let it stand.

> standards while Word, AFAIK, is not. If it were my choice, I would only 
> accept plain text and HTML (with images), but I am not going to fight 
> that battle. XML sources aside, we are simply relying on the existing 
> IETF policy for draft formats.

Yes.  We won't change that.

>> What about nroff?

Ditto.

> formats at this time (besides XML). With so many formats already allowed 
> it should be easy to add more later, if needed (i.e., if there is real 
> demand for more formats).

Yes.  I agree.

>> #    submitted; 2002: 5K; 2004: 7K).

'k' is the standard ISO suffix for thousand.

> I would rather not, but will do so if anybody else wants more definitions.

Might be a good idea, actually.

> not a formal flow chart. Besides the intent, the condition is even more 
> complex than you specified. For example, a submitter may pick the manual 
> route even if the draft is valid (perhaps there is a bug in the Post Now 
> action that the submitter knows about).
> 

Good, agreed.

> Is that better? At the very least it is easy to implement/satisfy, IMO.

Better, and looks good to me.

> post-a-draft-at-this-URL feature?

It's a secondary ease-of-use feature.  Nice to have, not necessary.
Skip it for now, or mention it as an optional feature for later.

> that is much easier to navigate than plain text. While minor differences 
> are unavoidable, any significant "makes no sense" comment would imply a 
> bug in HTML generation tool. This also gives us an opportunity to start 
> a [very] slow migration towards a generally-better default format 
> without much fighting with folks who still prefer plain text.
> 
> We are not accepting HTML drafts. We just render drafts with XML sources 
> as plain text and HTML...
> 
> I consider HTML rendering a useful experiment, but do not insist on it. 
> It just seems silly to have XML sources and not offer an HTML rendering 
> format that many folks prefer.

I'm divided here, mostly because I see the presentation of what is in
the repository as outside the scope of the tool.  I think the requirement
is good as it stands, exactly because it just provides the alternate HTML
format without going into how that is later made available or not.

> try to fight a DoS attack (see below for details).

Agreed.

> Sure, as a long-term goal. FWIW, I extract limited text from PDFs (using 
> a pdftotxt tool) quite often. I suspect we can, eventually, have some 
> kind of PDF templates or formats that would make this easier. Until PDF 
> extraction works, PDF-only drafts cannot be auto-posted, of course. If 
> PDF extraction is impossible, we should not accept PDF drafts at all, IMO.
>
> # If any error is found, automated posting becomes impossible (R113), # 
> but ...
> 
> As you know, the rules to identify what is a WG draft are quite complex 
> (I think Change log has some comments about this). Here, we are not 
> defining these rules. We expect the implementor to satisfy the 

Basically, you want to use the first group of /draft-ietf-([a-z0-9]+)-*/,
I'd say.  Currently, when chairs slip up, wg-drafts can happen to have 
names like draft-<wgname>-* or draft-name-<wgname>-*, but I'd like those
to explicitly have to go the manual route - let the tool only accept
as wg drafts drafts which have 'well-formed' wg draft names.

(as an aside, I slipped up this week when an author submitted a draft
 named draft-mip4-faerr-00.txt instead of draft-ietf-mip4-faerr-00.txt,
 and I'd really, really have wanted the tool to catch that, not let
 it through...)

> Definitely from the draft. See R16. Using clock would lead to a mismatch 
> between draft meta-data and draft text. Note, however, that the Toolset 
> should validate what it extracted so that draft version creation and 
> expiration dates satisfy IETF rules and make sense.
> 
> However, a malicious user can simply make a "typo" in your e-mail address.
> 

Mmm.  I'd say yes, require e-mail addresses for all authors.

> protected from receiving 500 e-mails).

Maybe add this rationale to that paragraph - it makes it clear that the
3 rev limit is DOS protection not primarily for the tool, but for the
people monitoring a draft.

> As we gain more experience, smarter schemes may become necessary. Or 

Agreed.

> infrastructure to allow gaps. Informal postings can use informal 

Yes, I agree.

> header is not included... Help?

"page.  Displaying a draft excerpt from the first line ...."

> Diff format(s) are out of this draft scope, IMO.

Agreed.

---

From: stanislav shalunov <[email-masked]>
Date: 22 Oct 2004 11:59:38 -0400

> Postscript and PDF have published definitions.

I know that.  They're still proprietary formats.  Change control is
with Adobe.  (There's nothing particularly sinister about being
proprietary---I use DVI, PostScript, and PDF all the time and, in
fact, lack any reasonable alternatives.)

In the case of PDF, this is not just a theoretical issue (as it would
be in the case of DVI): Adobe keep changing PDF so that I often have
difficulties reading the newest format (especially files produced by
Microsoft).

An even more troubling aspect of PDF is its ability to include
arbitrary OLE objects.  In a way, by allowing PDF one allows Microsoft
Word as well, as a PDF file can be a simple container that contains
only a single item: a Word document (or an Excel spreadsheet, for that
matter).

PostScript is better than PDF as an archival format as well: Adobe has
less incentive to change it (not that it doesn't) and it can't include
OLE objects (as far as I know).

PDF/A that Larry mentions is very promising.  Especially so if it
becomes an open format through ISO.

Religion is the opium of them asses.		--Karlm Arx

---

From: stanislav shalunov <[email-masked]>
Date: 22 Oct 2004 12:18:43 -0400

Alex Rousskov <[email-masked]> writes:

> Why do you think this feature is desirable?

On a personal level, that would allow me to keep using something
that's close to the current mode of submission (I currently send a URL
to [email-masked] and ask to post the draft there, which, in
my particular environment and with manual processing of requests at
the Secretariat even works in offline mode [web update and mail push
happen at about the same time]).  I don't even know how to send an
attachment from my MUA (on the about five occasions that I did send an
attachment, I typed the MIME headers manually).  I know a few people
who are similarly advanced-MIME-averse.

On a more general level, the message body is one of the MIME parts of
the message (if the message contains a MIME-Version header).  Talking
about tool simplicity, processing the body seems like the more uniform
approach than discarding it (and thus making it a special case).  If
someone cannot turn off signatures and legal disclaimers, he will have
to use an attachment, if email submission is desired.

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 10:54:35 -0600

On Fri, 2004/10/22 (MDT), <[email-masked]> wrote:

> I don't even know how to send an

Wow. And I thought all decent email clients support sending attachments  
without having the user to type MIME headers! You must be using something  
really cool that was not designed for [modern] email :-) But what do I  
know -- I am struggling with my new email client at the moment...

> to use an attachment, if email submission is desired.

The problem is not with folks that would use an attachment because they  
cannot turn signatures off, but with folks that would send a draft with a  
signature or legal crap embedded. Are we OK with posted drafts containing  
"This information is confidential and is intended for ..." crap,  
contradicting the IETF license? That's the common/likely problem I am  
worried about. I do not know how to solve pragmatically and suggest we  
simply avoid it.

Also, I wonder if email bodies are more prone to the following  
auto-modifications
	- changes in end-of-line coding
	- ">From" quoting
	- text wrapping
	- HTML-fication
and other similar "human-friendly" features.

Overall, it seems that drafts must be send "as is" and email bodies are  
often not sent as is because many email clients, historically, tailored  
their body-handling code for sending human-typed text not raw data.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 22 Oct 2004 13:14:52 -0400

[I *think* I'm mostly skipping the ones on which Henrik commented.]

> IETF jargon and ask questions if something is not clear.

In this case, the level of detail is OK.

> submitter. However, authentication part would fail because I cannot

So, it seems like you wouldn't be ``authenticated [...] as a lawful
submitter,'' and would not, therefore, be an authorized submitter in
this case, no?

> > #    submitted; 2002: 5K; 2004: 7K).

SI prefix `kilo-' is abbreviated as a lowercase `k'.  The uppercase
`K' is an abbreviation for kilo- in its 1024 sense, which is not what
you want, right?

> Is that better? At the very least it is easy to implement/satisfy, IMO.

Excellent.

> Are there many real use cases for post-a-draft-at-this-URL feature?

For what it's worth, that's how I submit drafts (I send a PGP-signed
message that contains a URL on my personal web page and a
cryptographic checksum of the file there, to be more precise).  Seeing
copies of other people's submission messages, I recall some doing it.
(I do it partly because I think it's less imposing to copy such a
message to the working group mailing list, since it's considerably
smaller than the draft.)

But your concerns about turning it into a client with no access
controls are understood.  However, it'd be similar to the W3 Validator
(or, for that matter, putting a link on a public page and waiting for
search engines to spider it).  It seems that the concern would be
taken care of if the Toolset obeyed robots.txt.

> that is much easier to navigate than plain text.

It seems to be a small step in the direction of RFCs in HTML.  I was
under the impression that you were opposed to backdoor practice
changes in other respects, so what makes this one different?

> Until PDF extraction works, PDF-only drafts cannot be auto-posted,
> of course.

Do we worry about cases of mismatch between PDF and plain text?  With
manual processing, the Secretariat can give it a cursory examination
and see that it looks like the same document with the same authors.
With automatic storage, that check would be gone.  It would seem to me
that to submissions with PDF should be processed manually.

> If PDF extraction is impossible, we should not accept PDF drafts at
> all, IMO.

In some limited cases, one can fairly easily extract text from PDF.
If the generation if by an unknown tool, though, it'd look like the
only way to extract text would be to render a bitmap and then OCR it.
(I hope we're not going there.)  Even innocuously produced PDF (e.g.,
ps2pdf) can have character tables that don't look like anything useful
(or at least Google couldn't find a way to index those files, and
their PDF extractor seems pretty decent).

> # If any error is found, automated posting becomes impossible (R113),

Ah, maybe a pointer to R113 in R15 then?

> have seen drafts before or, at least, can educate himself?

I see two ways of doing it:

1. Easy to maintain:
@fields = ($filename =~ m/draft-(\w+)-(\w+)-/);
$wg = $fields[1] if $fields[0] eq 'ietf';

2. Hard to maintain:
%wgs = (opes => 1,
        ippm => 1,
        tools => 1,
...
        );

@fields = ($filename =~ m/draft-(\w+)-(\w+)-/);
($person, $wg) = @fields if $wgs{$fields[1]}

I'd go for the first way any day.

> complex (I think Change log has some comments about this).

I don't know what they are.

> Definitely from the draft.

Should there be a requirement to compare the clock with the extracted
date and produce an error if the extracted date is more than a day in
the future (to allow for time zones) or more than a week in the past?

> By "This is no DoS protection", do you mean "there are ways around
> this DoS protection"? It seems to me that the protection makes sense
> (e.g., there will be folks that monitor a given draft and they should
> be protected from receiving 500 e-mails).

Ah, that makes sense.  How about something like inserting ``To protect
the mailboxes of those who are monitoring a particular draft,'' before
``Posting this''?

> simply "shutting down until humans can look at it" is the Right Thing
> to do when DoS is detected, *in this particular environment*. This
> approach is simple, robust, and effective. Again, IETF would not
> suffer much if

Would you consider changing the wording to make clear that you're not
trying to protect the tool from DoS by requiring it to shut down?
Maybe ``To protect the repository from a large volume of automated or
unusual submissions...''?

> And sometimes it is good because the people that grabbed it asked for
> a new revision. And sometimes while it may seem like they asked for a
> new revision (e.g., based on ID tracker output), they actually did not

Version numbers become quite a bit less useful when they might be the
same for different documents.  ``I'm reading -04 and it says...'' --
``Where are you looking?  I'm reading -04 and it doesn't say that.''

> That's an absolute requirement R22.

Then it can't be equal to an existing version number?  Or can it?

"You wake me up early in the morning to tell me I am right?  Please
wait until I am wrong."	-- John von Neumann, on being phoned at 10 a.m.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 11:58:18 -0600

On Fri, 2004/10/22 (MDT), <[email-masked]> wrote:

>> > #    authorized submitter: A lawful submitter authenticated by the >  
>> #    Toolset as such.
>> >

That's not the point. The point is that one is a lawful submitter (or not)  
before authentication starts. The Toolset does not authenticate lawfulness  
but identity (via verifying access to email):
	- step1: check that A (the given e-mail address) is an address of some  
lawful submitter
	- step2: check that submitter has access to A

> `K' is an abbreviation for kilo- in its 1024 sense, which is not what

Either would fall within the margin of error, but I do not care, and will  
use "k".

> changes in other respects, so what makes this one different?

Not sure what other backdoors you are referring to, but I am happy with  
making a small step towards HTML rendering of RFCs. Henrik has a good  
point -- if HTML is produced, it does not need to be displayed. We can toy  
with that second step later.

Alternatively, we can say that HTML production is out of scope. The draft  
rendering tool will do that (runtime? and cache results?).

> that to submissions with PDF should be processed manually.

I have no strong opinion here. I am OK with not permitting PDFs to be  
auto-posted
until they can be interpreted. I will make this change unless somebody  
objects.

> Ah, maybe a pointer to R113 in R15 then?

There are just too many places that would have to point to R113,  
unfortunately. Every validation requirement would have to point to R113  
because every validation may fail. I will emphasize the R113 applicability  
in the text.

> the future (to allow for time zones) or more than a week in the past?

I was going to leave specific values to the implementors, but can specify  
them if we think they are likely to get it wrong.

> ``Where are you looking?  I'm reading -04 and it doesn't say that.''

Indeed. However, I do not think that the Toolset can solve that problem
if people continue to look at non-posted drafts. My hope is that with the
Toolset in place, the number of public non-posted drafts will be  
negligible.
The Toolset enforces unique version numbers. Other means of sharing drafts  
do not.

> Then it can't be equal to an existing version number?  Or can it?

It cannot be. Does something imply it can? Sorry, I may have lost context  
here...

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 22 Oct 2004 14:15:51 -0400

"Alex Rousskov" <[email-masked]> writes:

> Wow. And I thought all decent email clients support sending
> attachments  without having the user to type MIME headers! You must be
> using something  really cool that was not designed for [modern] email

I use Gnus (as my headers mention), which I find indispensable for
large volumes of mail (scoring really helps on large discussion
lists); it has support for sending attachments -- I just don't
remember how to use it (because I don't typically need it).

Some people, including some IETFers, use /usr/bin/mail (combined with
procmail for sorting); that really has no attachment support for
sending.  And since you can't freely edit the headers in mail, even
typing the headers would not work.  It's difficult to say how many
people use this client because it leaves no signature in the headers.

There are, of course, always work-arounds (e.g., mpack).  It's more of
a matter of required procedural change for some people.  I realize
that I am in the minority since I don't use a web browser or Microsoft
Outlook to read my mail.  If the minority is small within the IETF, it
can safely be ignored.  Maybe I'll look at the headers on the IETF
lists.  Let's see:

#!/usr/bin/perl -w
use strict;

# Look at mail user agent versions.  Assume messages in the current
# directory, one per file (nnml in my case).

# Written by Stanislav Shalunov, http://www.internet2.edu/~shalunov/
# 2004-10-22

my %muas;
opendir DIR, '.' or die "opendir(.): $!\n";
$/ = '';        # Read by paragraph, to slurp the headers.
while (defined (my $file = readdir DIR)) {
        -r $file or next;
        open FILE, "<$file" or die "open($file): $!\n";
        my $header = <FILE>;
        $header =~ m/^From:\s*(.*)\s*\n/mi or next;
        my $from = $1;
        my $mua;
        $mua = $1 if $header =~ m/^User-Agent:\s*(.*)\s*\n/mi;
        $mua = $1 if (!$mua) and $header =~ m/^X-Mailer:\s*(.*)\s*\n/mi;
        $mua = 'Pine' if (!$mua) and $header =~ m/^Message-Id:\s*\<Pine/mi;
        $mua = 'unknown' unless $mua;
        # Get rid of version information.
        $mua =~ m/^(\w+)\W/ and $mua = $1;
        $muas{$from} = $mua;
}

print "$muas{$_}\n" for (sort keys %muas);

$ cd ~/Mail/mail.ietf           # Repository for general IETF mail.
$ ls | wc -l
    2214                        # 2214 messages currently kept locally.
$ mua-version | sort | uniq -c | sort -nr
 116 unknown
  68 Mozilla
  50 Microsoft
  40 Pine
  28 Internet
  23 QUALCOMM
  23 Apple
  21 Mutt
  16 Ximian
  11 Mulberry
   9 KMail
   5 Lotus
   4 Gnus
   3 VM
   3 Mew
   3 MH
   3 Foxmail
   3 ELM
   2 exmh
   2 Wanderlust
   2 Sylpheed
   2 SquirrelMail
   2 PocoMail
   1 Perl5
   1 Pegasus
   1 Openwave
   1 Novell
   1 Geckomail
   1 Eudora
   1 Earthlink
   1 EPOC
   1 Datula
   1 CrossPoint
   1 CommuniGate

[The numbers refer to different source addresses, not different
messages, so these approximate numbers of participants without paying
attention to the intensity of their participation.]

Many people (as many as use Microsoft clients and Mozilla, combined)
use mail user agents that do not specify either a User-Agent or an
X-Mailer header (and not Pine, which I treated as a special case).
All the popular point-and-shoot drag-and-put-on-meat-hooks
plug-and-die rodent-ridden attachment-happy user agents usually
specify their version (see the list above).

I think I might not be in such a tiny minority in this community.

> The problem is not with folks that would use an attachment because
> they  cannot turn signatures off, but with folks that would send a
> draft with a  signature or legal crap embedded.

People like that wouldn't be likely to know how to insert a draft in
the body of a message.

>       - changes in end-of-line coding

Why?  Are you thinking about people using MIME protection with
quoted-printable or base64 to encode bad ends of line?  I'm not sure
if there's a policy, but currently (almost?) everything is posted with
`\n' ends.  Which would be the case with sending unprotected ends of
line.

(If one wanted to protect different ends of line, this could be
accomplished by quoted-printable or base-64 in the body or in an
attachment with about equal ease -- or difficulty.)

>       - ">From" quoting

I just looked and the code in Postfix that does this nonsense is not
paying attention to MIME structure.  But in any case, the draft text
is indented usually, so this would only be a problem if a standard
(non-numbered) section name started with ``From ''.  That's not the
case.

A nasty case would be an author whose last name is ``From.''  I've not
met any Froms, but they'd probably need to use the web interface, or
pray that the attachment works, or specify their name in all
uppercase, or use their first name along with their last name in the
footer.  Whatever they do, it'll look like a typo to most people
anyway.

>       - text wrapping

That's a valid concern.  Hopefully, idnits would catch that, would it
not?

>       - HTML-fication

Same as with signatures, I think.  Someone using a MUA that sends HTML
won't know how to insert a draft in the message body.

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

---

From: stanislav shalunov <[email-masked]>
Date: 22 Oct 2004 14:48:11 -0400

"Alex Rousskov" <[email-masked]> writes:

> Not sure what other backdoors you are referring to,

Other formats, for example.

> but I am happy with making a small step towards HTML rendering of RFCs.

This would seem to need community discussion.  The disadvantages of
plain text are clear, but so are the advantages.

> Henrik has a good point -- if HTML is produced, it does not need to
> be displayed. We can toy with that second step later.

This, to me, sounds too similar to ``we don't actually want to use
this {database,surveillance tool,instrument for income
redistribution}; at this point we simply propose to invest in building
it, while actual use would be discussed later.''  Politicians do that,
we should not.  If the community wants I-Ds (and perhaps even RFCs) in
HTML, fine.  If it doesn't, we shouldn't invest in building the tools
for it.

> Alternatively, we can say that HTML production is out of scope.

That would be fine.

> I was going to leave specific values to the implementors, but can
> specify  them if we think they are likely to get it wrong.

Maybe not the specific values, but a requirement for some check could
be useful.  (Also, the one-day-in-the-future part might be gotten
wrong by an implementor.)

> The Toolset enforces unique version numbers.

Good, we're in violent agreement.

> It cannot be. Does something imply it can?

When looking at R21, I get this impression (violating R21 is a
warning, not an error).  This might contradict R22, which I don't find
particularly clear.  What's a ``correct revision number with respect
to already published revisions, if any''?  In light of text in R21,
this is not very clear.

Clothes make the man.  Naked people have little or no influence on
society.                                             -- Mark Twain

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 13:31:02 -0600

Since nobody is supporting my position, I will add
the in-body email submission feature back.

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Oct 2004 00:25:45 +0200

Touching on just a few of the points, below

...
> point -- if HTML is produced, it does not need to be displayed. We can 
> toy  with that second step later.

Sounds good to me.

> Alternatively, we can say that HTML production is out of scope. The 
> draft  rendering tool will do that (runtime? and cache results?).
> 

I'm not sure we have a strong reason to go either way, and would propose
that we don't specify this, but leave it to the implementers in that 
case.

...
> specify  them if we think they are likely to get it wrong.

No, leave it to the implementers.

> The Toolset enforces unique version numbers. Other means of sharing 
> drafts  do not.
> 
> It cannot be. Does something imply it can? Sorry, I may have lost 
> context  here...

Don't know, but anyway, it seems right to me to enforce contiguous
non-overlapping numbers.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Oct 2004 00:32:47 +0200

> the in-body email submission feature back.

And here I've only been away from mail for 10 hours or so, to
take care of some visitors from abroad :-)

I think there are enough of problems with separating out text
before and after the actual draft text that it would be best
not to go there, if we can avoid it.

I was going to propose that instead of accepting draft in the
body, we consider accepting links to drafts available by http,
as suggested earlier by Stas, as a less problematic compromise.

What say you (and I'm prepared to duck if you both throw eggs :-)

	Henrik

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 17:01:56 -0600

> as suggested earlier by Stas, as a less problematic compromise.

Reliable support for URL-fetching would take a lot of cycles to implement,  
IMHO, with little Toolset code reuse. I can add it as a useful feature,  
but I am reluctant to suggest that it is supported soon.

Alex.

P.S. I should remember to use Stas' trick next time I am up against the  
IETF meeting cut-off deadline -- send a URL and buy yourself a few more  
editing days until the Secretariat gets to it! I bet a checksum was not  
required :-).

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Oct 2004 01:11:28 +0200

Alex Rousskov wrote:
> Reliable support for URL-fetching would take a lot of cycles to 
> implement,  IMHO, with little Toolset code reuse. I can add it as a 
> useful feature,  but I am reluctant to suggest that it is supported soon.

Hmm, maybe we have different experiences here - I expect it to be as
simple as

"
import urllib
fh = urllib.open(url)
draft = fh.reaad()
fh.close()
"

which is about what it would come to in Python...

	Henrik

> editing days until the Secretariat gets to it! I bet a checksum was not  

Devious ,,:-)

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 17:21:51 -0600

> Hmm, maybe we have different experiences here - I expect it to be as

The above code would probably fail in many cases and leave the submitter  
in the dark as to why.
Hacking this in is easy; doing it Right is not, IMO. But, again, I do not  
have strong preferences here.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 22 Oct 2004 23:29:28 -0600 (MDT)

On Fri, 22 Oct 2004, Henrik Levkowetz wrote:

> Basically, you want to use the first group of 
> /draft-ietf-([a-z0-9]+)-*/, I'd say.  Currently, when chairs slip 
> up, wg-drafts can happen to have names like draft-<wgname>-* or 
> draft-name-<wgname>-*,

or even draft-lastname-* (our reviewers gave such examples).

> but I'd like those to explicitly have to go the manual route - let 
> the tool only accept as wg drafts drafts which have 'well-formed' wg 
> draft names.

While documenting that, I realized that we may have a problem. The 
Toolset may not be able to distinguish badly-named WG drafts from 
well-named individual drafts and, hence, will either prohibit 
auto-posting of 00 versions of many valid individual drafts OR allow 
auto-posting of 00 versions of some WG drafts without Chair approval!

> (as an aside, I slipped up this week when an author submitted a 
> draft named draft-mip4-faerr-00.txt instead of 
> draft-ietf-mip4-faerr-00.txt, and I'd really, really have wanted the 
> tool to catch that, not let it through...)

At this late hour, it seems to me that the solution is to say that if 
and only if the draft name matches /^draft-ietf-([a-z0-9]+)/, the 
draft is treated as a WG draft. WGs and Chairs that do not obey the 
convention will have to deal with the consequences. Note that since it 
is easy to resubmit with the right name, it may not be a big deal if a 
Chair makes a mistake.

The Toolset should say how it is treating a draft so that the 
submitter knows what is going on.

The Toolset may warn if a non-WG draft contains a known working group 
name after /^draft-/. Or, better, if the token in that position does 
not match any of the author last names or email "logins".

IIRC, Brian Carpenter (CCed) supports the above
let-them-deal-with-their-own-mess solution.

An alternative is to ask the submitter of 00 version whether the draft 
is a WG draft, but I am not sure that is any better than the above.

Comments?

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 23 Oct 2004 10:33:13 +0200

Alex Rousskov wrote:
>> /draft-ietf-([a-z0-9]+)-*/, I'd say.  Currently, when chairs slip up, 
>> wg-drafts can happen to have names like draft-<wgname>-* or 
>> draft-name-<wgname>-*,
> 
> 
>> but I'd like those to explicitly have to go the manual route - let the 
>> tool only accept as wg drafts drafts which have 'well-formed' wg draft 
>> names.
> 
> 

Noo, I don't think that's right - at least you'll have to give me
some examples so I can see it.  An individual draft may _not_ be
named draft-ietf-*, while WG drafts which are not named draft-ietf-*
should not be automatically processed.  That's a clear split, and
clear decision point, no?  Or have I missed some aspect of this?

>> and I'd really, really have wanted the tool to catch that, not let it 
>> through...)
> 
> 
> and only if the draft name matches /^draft-ietf-([a-z0-9]+)/, the draft 
> is treated as a WG draft. WGs and Chairs that do not obey the convention 
> will have to deal with the consequences. Note that since it is easy to 
> resubmit with the right name, it may not be a big deal if a Chair makes 
> a mistake.

Ah, yes, it seems we're in agreement, after all.

> The Toolset should say how it is treating a draft so that the submitter 
> knows what is going on.

Yes

> name after /^draft-/. Or, better, if the token in that position does not 
> match any of the author last names or email "logins".

Yes

> is a WG draft, but I am not sure that is any better than the above.

No, it leads to new choices and adds complexity without giving
a noticeably better solution, I think.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 24 Oct 2004 22:58:07 -0600 (MDT)

> not to go there, if we can avoid it.

Since validation routines would reject virtually all drafts with 
signatures and such, I think we can accept in-body submissions. It 
seems to me that we are opening a can of worms with the email 
submission interface itself (due to popular demand, of course); 
killing this particular worm seems pointless.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 25 Oct 2004 11:30:07 -0400

> fh.close()

Or, in a different language,

use LWP::Simple;
my $draft = get($url) or die "could not fetch draft at $url\n";

[The use of die assumes HTTP headers are already sent.]

But one could, of course, get fancy and give the submitter an error
code by switching from get() to getstore().

With the instantaneous workings of the Toolset (as opposed to
human-timescale Secretariat), URL submission via email would become
less useful as a disconnected feature.

Alex Rousskov <[email-masked]> writes:

> P.S. I should remember to use Stas' trick next time I am up against
> the  IETF meeting cut-off deadline -- send a URL and buy yourself a
> few more  editing days until the Secretariat gets to it! I bet a
> checksum was not  required :-).

But I always send a cryptographic checksum along (in a PGP-signed
message), so no cheating here.  By the way, how about we make the
requirements a little less agnostic with respect to (cryptographically
understood) integrity?  Of course, this is not the first priority, but
eventually secure communication with the I-D repository should be
available to those who want it.  I'd argue it's a higher priority item
that, say, PDF parsing.

"I didn't attend the funeral, but I sent a nice letter saying that I
approved of it."				-- Mark Twain

---

From: "Alex Rousskov" <[email-masked]>
Date: Mon, 25 Oct 2004 09:45:32 -0600

On Mon, 2004/10/25 (MDT), <[email-masked]> wrote:

> how about we make the

I agree that PDF parsing should have lower priority than better  
authentication. On the other hand, I do not think that ID Submission draft  
is the place to document better authentication. Even the current level of  
authentication detail in that draft is excessive, IMO. There needs to be a  
stand-alone document that describes how IETF tools should authenticate  
their users when authentication is needed.

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Oct 2004 09:40:38 -0700

>is easy to resubmit with the right name, it may not be a big deal if a 

I know the hour is now beyond late, but here's my view anyway: for
-00 documents, draft-ietf-* is a "WG draft", draft-lastname-* is not.
For non-00s, there's a database that knows if something that's not
draft-ietf-WG is still a WG draft.

  Bill

---

From: "Alex Rousskov" <[email-masked]>
Date: Mon, 25 Oct 2004 13:24:25 -0600

> draft-ietf-WG is still a WG draft.

The Toolset does not currently care about WG flag for versions other than  
00. The only exception I can think of is allowing WG Chair to post an N+1  
version of a WG draft. In the future, there may be features like automated  
WG notification or automated WG pages updates that would benefit from  
correct WG flag setting. On the other hand, if IETF starts to enforce the  
naming policy, there will be no poorly named drafts in the future!

In your opinion, should we use a simple-but-rigid scheme in hope that  
uniform naming of WG drafts is going to be enforced? Or should we assume  
no long-term enforcement and opt for a complex-but-flexible scheme instead?

Thanks,

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Oct 2004 12:31:11 -0700

>uniform naming of WG drafts is going to be enforced?

I think of it a different way: the only possible name for a WG -00
is draft-ietf-WGNAME.  If it's not named that, then it's not a WG -00.
The WG chair can later reclassify it to become a WG document by asking
the secretariat to modify the database, but that's the part that this
doesn't care about.

  Bill

---

From: stanislav shalunov <[email-masked]>
Date: 25 Oct 2004 16:25:38 -0400

> is draft-ietf-WGNAME.  If it's not named that, then it's not a WG -00.

Amen.

> the secretariat to modify the database, but that's the part that this

I would go even further: if it becomes a WG draft, the name gets
changed to draft-ietf-[...].  I'm not really sure how this compares to
existing practice, but the ability to tell, at a glance, whether a
draft is individual is actually no less useful for humans than for the
submission tool.  And while the submission tool might keep a database,
humans have difficulty keeping databases in their heads; in this case,
the advantages of a database over a naming convention aren't even
clear.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 25 Oct 2004 20:04:15 -0600 (MDT)

>> is draft-ietf-WGNAME.  If it's not named that, then it's not a WG -00.

That's what we have codified already.

>> The WG chair can later reclassify it to become a WG document by 
>> asking the secretariat to modify the database, but that's the part 
>> that this doesn't care about.

Except for giving WG Chairs permission to submit WG drafts. If the 
Toolset does not know that a draft is a WG draft, then the Toolset 
does not let the WG Chair submit new versions. This is not a big deal.

> changed to draft-ietf-[...].

That's what we have codified already, essentially (because one can 
always change a draft name by submitting a new draft with the new 
name). Bill is suggesting to give WGs flexibility in naming drafts 
after version 00.

As Stas, I would prefer a simple and consistent (albeit rigid) scheme 
where no external mapping is needed because I have not seen any 
arguments why keeping the same draft name is more important than 
giving readers and tools a simple way to distinguish WG drafts.

I would also give authors tools to specify that a given draft forks 
from another draft, so that the draft history is maintained. That 
ability would be useful in general, not just for drafts becoming WG 
drafts.

Bill, what is the motivation behind letting draft names NOT reflect 
their status for version other than 00?

Thank you,

Alex.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 26 Oct 2004 13:11:01 +0200

--On 25. oktober 2004 20:04 -0600 Alex Rousskov 
<[email-masked]> wrote:

> Bill, what is the motivation behind letting draft names NOT reflect their
> status for version other than 00?

The typical case has been where the author/editor thinks that the last 
version of the individual-named draft is already ready to pass to the IESG, 
so one "shouldn't bother".

The typical case is that this turned out to not be the case......

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 26 Oct 2004 09:36:55 -0600

On Tue, 2004/10/26 (MDT), <[email-masked]> wrote:

> version of the individual-named draft is already ready to pass to the  
> IESG, so one "shouldn't bother".
>

Would it be so bad to rename the draft at that point in time (as opposed  
to re-classifying it as a WG draft)? Especially if we have a way to "link"  
to the original draft to preserve history?

Thanks,

Alex.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2004 14:09:10 +0200

The only problem case would be if somebody shows up whose
own name happens to be ietf. Now that may seem unlikely, but
we are a multinational organisation, so we can't totally
exclude it.

However, I won't lose sleep over it, until Mr or Ms Ietf does
become an active IETF author.

      Brian

P.S. Of course, there's a DOS attack in which a bunch of people
legally change their name to Ietf :-)

Henrik Levkowetz wrote:
>>> named draft-mip4-faerr-00.txt instead of