Subject: [Tools-discuss] RE: Mangled Internet-Drafts

From: Eric Burger <[email-masked]>
Date: Wed, 3 Nov 2004 07:28:50 -0500

As someone who travels *a lot*, and often has spotty connectivity, I would
strongly urge a SMTP Submit mechanism to parallel a web-based tool.  For
example, one could have a standard format for the metadata entered in the
first two pages (XML? 822-style keyword-value?) followed by the document.  A
reply stating the submission succeeded or failed would be good.

One thing that made e-mail a killer application is its asynchronous
communication nature.  Sure, IM (in this case, a web page) is great, but it
isn't everything...

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]]
> Sent: Tuesday, November 02, 2004 7:15 PM
> To: Rohan Mahy
> Cc: WG Chairs; Tools Team Discussion
> Subject: Re: Mangled Internet-Drafts
> 
> 
> Hi Rohan,
> 
>     The tools team has been working on specifying such a web 
> interface.
> Maybe you'd like to review the draft:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-sub
mission-06.txt

	Henrik

Rohan Mahy wrote:
> Hi,
> 
> My proposal is to use a web form to submit internet-drafts instead of an 
> email.  The form can automatically check for appropriate formatting, 
> boilerplate, and other ID nits, and return an immediate response 
> indicating the success or failure of the submission. The form could also 
> optionally check for WG chair approval for new WG IDs.  The drafts that 
> pass the pre-check could be automatically included in the repository, or 
> quarantined for inspection and release by the secretariat staff.
> 
> I realize that this approach has been discussed before and rejected for 
> historical reasons.  I do not intend to start a debate on the merits of 
> using web pages instead of email, merely to publicly indicate my support 
> for the approach.
> 
> thanks,
> -rohan

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

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 03 Nov 2004 09:18:25 -0700

FYI: The Toolset proposed in  
http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-06.txt  
includes both email and web interfaces.

Alex.

On Wed, 2004/11/03 (MST), <[email-masked]> wrote:

> As someone who travels *a lot*, and often has spotty connectivity, I  
> would strongly urge a SMTP Submit mechanism to parallel a web-based tool.
>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 3 Nov 2004 08:23:47 -0800

At 7:28 AM -0500 11/3/04, Eric Burger wrote:
>strongly urge a SMTP Submit mechanism to parallel a web-based tool.

At some point in your travelling, you must have internet connectivity 
to send/receive mail. You should be able to do a web form-submit at 
that time. True, you cannot queue these up as easily as you can your 
outgoing email, but you still can do it.

Designing two parallel systems is much more error-prone than designing one.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 03 Nov 2004 10:27:35 -0700

On Wed, 2004/11/03 (MST), <[email-masked]> wrote:

>> would
> At some point in your travelling, you must have internet connectivity to  
> send/receive mail. You should be able to do a web form-submit at that  
> time. True, you cannot queue these up as easily as you can your outgoing  
> email, but you still can do it.
>

I am not a big fan of multiple interfaces in early Toolset versions.  
Moreover, email draft submission has serious drawbacks (documented in  
Tools draft). However, given the large number of IETFers that have a very  
strong preference for using email for draft submission, the Tools team  
felt that we have to provide that option in order to get the tool  
"approved" by IETF.

Unless we have misjudged IETF feelings, it looks like every major IETF  
tool would have to have an email interface if such interface is  
technically possible. Perhaps we should place scary-looking ASCII-drawn  
wolves in our signatures to convince IETFers to stay away from email draft  
submissions? :-)

Alex.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 3 Nov 2004 09:50:02 -0800

At 10:27 AM -0700 11/3/04, Alex Rousskov wrote:
>Moreover, email draft submission has serious drawbacks (documented 
>in Tools draft). However, given the large number of IETFers that 
>have a very strong preference for using email for draft submission, 
>the Tools team felt that we have to provide that option in order to 
>get the tool "approved" by IETF.

<sigh> Probably right, although I think it is more due to inertia 
than to good engineering thinking.

>Unless we have misjudged IETF feelings, it looks like every major 
>IETF tool would have to have an email interface if such interface is 
>technically possible. Perhaps we should place scary-looking 
>ASCII-drawn wolves in our signatures to convince IETFers to stay 
>away from email draft submissions? :-)

The mail-based tool is possible, it is just much harder to get right 
in all cases because the draft can get mangled before it hits the 
Secretariat's mail server. Once the message is at the Secretariat, 
there is no problem; there are plenty of Perl (and so on) tools that 
can extract the I-D just fine.

Instead of trying to scare people away from mail submission, there 
might just be some mail feedback that says "Please check your draft 
for formatting after it is published. If the formatting is incorrect, 
submit a revised draft (after bumping the -nn number) through the web 
interface, and use the web interface in the future."

--Paul Hoffman, Director
--VPN Consortium

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 03 Nov 2004 11:09:34 -0700

On Wed, 2004/11/03 (MST), <[email-masked]> wrote:

> I think it is more due to inertia than to good engineering thinking.

Agreed.

  Instead of trying to scare people away from mail submission, there might
> just be some mail feedback that says "Please check your draft for  
> formatting after it is published. If the formatting is incorrect, submit  
> a revised draft (after bumping the -nn number) through the web  

Email submissions are validated just like web submissions. There is even a  
preview provided in the submission response. I suspect that the vast  
majority of formatting errors caused by email agents can be detected  
automatically, and many cases are already checked for by Henrik's idnits  
tool. Some formatting errors will prevent the draft from being posted and  
some will just generate a warning, but even a warning should be sufficient  
for most submitters to get worried and check what has actually happened.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 03 Nov 2004 13:18:24 -0500

One thing I always do (and the Secretariat probably ignores) is
provide a cryptographic checksum of the draft as I have it.  By so
doing, I provide the Secretariat with a means to ascertain that the
draft wasn't mangled anywhere.

I think this is a reasonable measure to take regardless of true
security mechanisms such as PGP.  Indeed, it would help catch cases
where a PGP-signed draft is published rather than the PGP output
(these can differ if there are lines that start with a dash).

This measure is presently not in
draft-ietf-tools-draft-submission-06.txt, but I think it could be
there.  I think it should be.

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

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra

---

From: "Alex Rousskov" <[email-masked]>
Date: Wed, 03 Nov 2004 11:52:35 -0700

> draft wasn't mangled anywhere.
...
> there.  I think it should be.

Current email interface requires no extra metadata. Only sender's address  
is used. Thus, we are not talking about a gradual improvement but a  
significant change here, especially for in-body submissions. Also, I am  
not sure whether email systems are prohibited from modifying plain text  
messages. If they can modify some messages (e.g., to do end-of-line  
conversion), then a checksum would be useless.

Would accepting compressed drafts be a better option? Compression gives  
you a reliable checksum and might be useful for low-bandwidth links. Web  
interface can accept compressed drafts as well. Accepting compressed  
content would be a gradual improvement since the Toolset has to deal with  
various encodings already.

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 03 Nov 2004 20:29:06 +0100

Alex Rousskov wrote:
> Current email interface requires no extra metadata. Only sender's 
> address  is used. Thus, we are not talking about a gradual improvement 
> but a  significant change here, especially for in-body submissions. 

I agree 

> Also, I am  not sure whether email systems are prohibited from modifying 
> plain text  messages. If they can modify some messages (e.g., to do 
> end-of-line  conversion), then a checksum would be useless.

I'm also not sure, but a bit wary about this

> you a reliable checksum and might be useful for low-bandwidth links. 
> Web  interface can accept compressed drafts as well. Accepting 
> compressed  content would be a gradual improvement since the Toolset has 
> to deal with  various encodings already.

I think this is a good path of gradual improvement :-)

	Henrik

---

From: stanislav shalunov <[email-masked]>
Date: 03 Nov 2004 15:49:57 -0500

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

> address is used. Thus, we are not talking about a gradual
> improvement but a significant change here, especially for in-body
> submissions.

Understood and agreed.

> Also, I am not sure whether email systems are prohibited from
> modifying plain text messages. If they can modify some messages
> (e.g., to do end-of-line conversion), then a checksum would be
> useless.

Well, providing a checksum would be optional and would be rather the
point of making sure that the file, as a byte sequence, was
transferred intact.  It'd work for many people.  It'd fail for some
(e.g., those with non-'\n' line endings locally).

> Would accepting compressed drafts be a better option?

Quite possibly.  I forget the resolution of the issue with taking
URLs.  If the tool takes URLs, then a cryptographic checksum would
still be useful (including for real security rather than a simple
check).

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 2004 15:04:37 +0100

> end-of-line  conversion), then a checksum would be useless.

I am very sure - some mailers mangle messages, and some mangle them a LOT.

- End of line conversion (routine)
- Stripping trailing spaces (rarer)
- Conversion of "From" to ">From" (extremely common)
- Converting between 8-bit, quoted-printable and base64 at random
- long line breaking (rare)
- Swapping headers, including headers of inner body parts
- sheer mangling, especially of non-ASCII characters (variable)

All of this means that signatures of email messages can only be done 
reliably by first reducing them to a canonical form, which should be 7-bit 
encoded, and then calculating a checksum over that - not the original form.

See RFC 1864 for more data on one such scheme.

                       Harald