Subject: [Tools-team] Comment on draft-ietf-tools-draft-submission-06

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Nov 2004 15:23:10 -0500

A minor comment: The draft repeatedly refers to CGI, a very specific 
technology for active web pages. However, most reasonable modern 
implementations will use something other than CGI, such as PHP, ASP, 
Java servlets and the like. None of these are accurately described as CGI.

You are also making an implicit assumption, it seems, that might be 
worth calling out, regarding user authentication. You seem to assume 
that there is no user authentication for the poster, although your 
security consideration section talks about some email reading 
verification. From a quick read, I don't see this described anywhere.

I think you will need user accounts in any event for working group 
approvals.

In any event, I think it would be helpful to describe explicitly whether 
you're looking at a stateless model (where anybody can submit the draft, 
with no authentication) or a stateful model (where users have accounts, 
only certain users can update a draft, etc.). I think both will work for 
submission, unless you worry about impostors.

My personal experience after thousands of papers automatically submitted 
(see edas.info): email submission to robots sucks. It works well enough 
for 90+% of the cases, but requires manual intervention for the rest. 
Just to name a few problems: mailers might automatically attach 
signature bodies, so the recipient program has to be smart enough to 
know which body part is the draft and which is a vCard and whether there 
might be several different drafts or draft formats attached. It has to 
deal with encrypted or signed mails, gzip'ed and compressed body parts. 
Not all mailers use Content-type correctly. You'll get TNEF attachments 
courtesy of Outlook or people who don't understand the difference 
between cut-and-paste and attach. You'll get "automated" friendly 
conversion of TXT into HTML. I tried programming all the cases for my 
conference tool and in the end, just gave up - it would invariably fail 
for somebody just before the submission deadline. Lots of people wanted 
email submission a few years ago, but I haven't heard anybody 
complaining about the removal so far.

Henning

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

---

From: "Alex Rousskov" <[email-masked]>
Date: Mon, 08 Nov 2004 10:01:48 -0700

> Java servlets and the like. None of these are accurately described as  

IMO, CGI is a reasonable modern technology to implement the web interface  
of the ID submission Toolset. Said that, I think the choice of low-level  
technology should be left to the implementors. I hope that the implementor  
can pick the right technology given all the factors (e.g, code reuse  
between web and email interfaces).

I found two references to CGI in the draft. I agree that the draft is not  
clear whether CGI is mandated. It is not. Will fix.

> verification. From a quick read, I don't see this described anywhere.

    If a given submitter email address belongs to a lawful submitter
    (i.e., belongs to one of the lawful categories below), the Toolset
    performs submitter authentication during a Post Now action (R19/a).
    Otherwise, an error is reported (R118/a).

and

    External meta-data contains submitter email address.  As a part of
    the validation procedure, the Post Now action authorizes the
    submitter.  The initial action implementation checks that the
    submitter has access to email sent to that address (R38/a).
    Eventually, the Toolset should accept client certificates signed by
    IETF, PGP-signed email, and/or other forms of client-side
    authentication to eliminate the weak and annoying email access check
    (R110/c).  If submitter authentication fails, the submission
    eventually and silently times out (R39/a).

Do you think more requirements need to be added? If yes, what requirements?

> I think you will need user accounts in any event for working group  

Specifics of the WG approval mechanism is out of this draft scope. I agree  
that, eventually, IETF should have optional accounts for those who want to  
use automated means of authentication. I am worried that mentioning  
anything like this in the ID submission draft will delay draft approval  
because many IETFers think that user accounts are evil. Hopefully, when  
several deployed tools can benefit from decent user authentication, we can  
document and recommend deployment of a simple but general/comprehensive  
IETF authentication framework.

> submission, unless you worry about impostors.

It is something in-between. There is state, but not explicit accounts.

> (see edas.info): email submission to robots sucks.
[good justification snipped]

Personally, I agree. Unfortunately, too many IETFers demand email  
interface because they want to "submit" drafts while not connected to the  
Internet. The current consensus is that the draft may not get approval if  
it lacks email interface.

However, it might be worth [re]considering email interface priority. Given  
implementation and maintenance costs, can we move email interface to the  
Enhancements stage? Can the Toolset handle 90% of submissions without  
email interface?

Thanks a lot for your comments! Please let me know if any improvements  
other than making CGI non-normative are needed.

Alex.