Subject: [yaco-idsubmit-tool] Testing notes / Henrik / March 11

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 11 Mar 2011 18:09:35 +0100

Testing issue:

  * I'm not seeing any posting confirmation emails going out to the
    testing address, which makes it impossible for me to carry through
    the testing to a final post, and verify that the document is online.

Bugs:

  * Failed idnits run on second submission?  I did one upload of
    draft-ietf-dnsext-axfr-clarify-16.txt, which had some metadata
    flaws, fixed those and uploaded again.  The (failed) idnits results
    from the second upload is incomplete, showing only this:

	"idnits 2.12.07 

	/var/www/staging/draft-ietf-dnsext-axfr-clarify-07.txt:"

    Running idnits 2.12.07 locally on the draft produces the expected
    output.

  * Abstract extraction.  Processing draft-ietf-dnsext-axfr-clarify-16.txt
    gives an abstract which includes the first 2 paragraphs from the
    Introduction section.  You should probably add a condition which cuts
    the abstract when a line matching "^ *[0-9]+\.? " is found, to stop at
    the first numbered section.

  * Abstract extraction (II).  Processing draft-eastlake-sha2b-05 results
    in an abstract which is cut short.  The last line of the first paragraph,
    and the entire second paragraph of the abstract is missing.

Flaws:

  * It's unnecessarily hard to upload a fixed version of a draft after
    flaws has been found in a first upload.  You have to either remember
    to cancel on the check page, or follow the link provided to go back
    and do it later.  I'd prefer that for a failed upload (idnits or
    meta-data failures) a new upload would automatically cancel the
    previous one; at least a new upload from the same IP address.

  * Also, cancelling a submission with idnits or meta-data errors should
    not cause an 'Are You Sure' dialog.

  * When the draft name found in the text of an uploaded draft contains
    characters which are not permitted, there's an error message next to
    the upload filename box.  This can be misleading, especially if the
    filename of the upload doesn't violate the rule.  Please change the
    message "Filename contains non alpha-numeric character: %s" next to
    the upload filename box to be a metadata error on the check page,
    and change the text to something like "The draft name found in the
    document, '%s', contains one or more alphanumeric characters: '%s'."

  * On at least one occasion, (draft-ietf-v6ops-ipv6-cpe-router-08.txt),
    the first time I clicked the 'Post' button I was just returned to the
    same page.  A second click on 'Post' resulted in the submitter auth
    page.

Nits:

  * On the check page, there's initially a large blank area above the
    Meta-Data area, which then (as the style sheet is read in??) reduces
    to a reasonable height.  Please make this appear the same from the
    start.  If this is caused by the idnits page element, you could maybe
    take it out of the regular html placement flow by giving it absolute
    placement from the start?  (Just guessing here as to the cause...)

  * If a draft name is found in multiple places on the first page, it would
    make it easier to correct for instance a bad revision number if the
    meta-data error message would quote the full line where the bad rev.
    number was found.

The notes above is what I have from testing 8 drafts which have been
troublesome in the past.  As soon as the first bug is fixed, so it's
possible to do repeat submissions with idnits fixes, I'll test more.

Best,

	Henrik

---

From: "Emilio A. Sánchez López" <[email-masked]>
Date: Sat, 12 Mar 2011 18:34:10 +0100

Hi Henrik,

>      the testing to a final post, and verify that the document is online.

    The testing address is redefined in the settings_local of beta using 
EMAIL_COPY_TO so I can have access to the emails. I can revert to the 
original configuration or better add the two email addresses.

>      Running idnits 2.12.07 locally on the draft produces the expected

    Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/611

>      the first numbered section.

    The only problem with this regular expression is that some drafts 
contain lines beginning with a number, an optional dot and a space like in:

    http://tools.ietf.org/id/draft-ietf-dnsop-default-local-zones-14.txt
    http://tools.ietf.org/id/draft-ietf-hokey-ldn-discovery-06.txt

    But it works pretty well if we check that the previous line was a 
blank line.

>      and the entire second paragraph of the abstract is missing.

    I have extended the abstract extraction to fix that bug and the 
previous one at http://wiki.tools.ietf.org/tools/ietfdb/ticket/612

>      not cause an 'Are You Sure' dialog.

    Added at http://wiki.tools.ietf.org/tools/ietfdb/ticket/613

>      document, '%s', contains one or more alphanumeric characters: '%s'."

    That error is a critical error (critical errors are the ones that do 
not allow to reach the status page). If some extrange caracters apear in 
the draft name then draft.py is unable to extract name and revision. 
Also the draft name is used as filename to the files when saved into the 
stagin area so it's a bad idea if the have non alpha characters.

    In the old tool this one was also a critical error that doesn't 
allow to proceed to status page. Do you really need to reach the status 
page in these cases? Maybe will be enough if we change the error message.

>      same page.  A second click on 'Post' resulted in the submitter auth

    It's a reproducible bug, that is good.

    Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/613

>      placement from the start?  (Just guessing here as to the cause...)

    Wow, you have a fast eye. I had to try with different browsers until 
I see this behavior.

    Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/615

>      meta-data error message would quote the full line where the bad rev.

    I have decorated the two pages dialog so it highlights the draft 
name that contains the error. I think this way is fast and more graphical.

    See at http://wiki.tools.ietf.org/tools/ietfdb/ticket/616

> possible to do repeat submissions with idnits fixes, I'll test more.

    I have applied all the fixes and added the original testing email 
address to settings_local in the beta server.

    Best,

>
> Best,
>
> 	Henrik
> _______________________________________________
> yaco-idsubmit-tool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yaco-idsubmit-tool

-- 
Emilio A. Sánchez
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 13 Mar 2011 18:04:29 +0100

Hi Emilio,

> original configuration or better add the two email addresses.

Yes, please; that would make testing all the way through to posted document
possible.

>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/611

Thanks.

>     http://tools.ietf.org/id/draft-ietf-hokey-ldn-discovery-06.txt

Ah.  Right.

>     But it works pretty well if we check that the previous line was a 

Right.  Very good.

> previous one at http://wiki.tools.ietf.org/tools/ietfdb/ticket/612

Thanks.

> page in these cases? Maybe will be enough if we change the error message.

I understand your reasoning, and if the draft can't be saved in the staging
area you shouldn't really go on to the check page.  However, the error message
needs to be different, as you say; and I also think it shouldn't be presented
as an error related to the upload form entry -- that gave me the impression that
the upload hadn't succeeded.  Better make it an error message presented just
above the set of upload form entries, and say that the upload succeeded, but
the file could not be saved in the staging area because <reason>, where <reason>
could be that no document filename was found in the document, or that the
document filename found contained disallowed characters, or ...

>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/613

Thanks.

>     Wow, you have a fast eye. I had to try with different browsers until 

Longer load time at a distance is more likely the reason, I think :-)

>     Fixed at http://wiki.tools.ietf.org/tools/ietfdb/ticket/615

Thanks.

>     See at http://wiki.tools.ietf.org/tools/ietfdb/ticket/616

Excellent.  Thanks.

> address to settings_local in the beta server.

Splendid!  Thanks.

Best regards,

	Henrik

---

From: Tony Hansen <[email-masked]>
Date: Sun, 13 Mar 2011 15:04:47 -0400

Here's a difficult one for the tool:

draft-ietf-yam-pre-evaluation-template-04.txt
draft-ietf-yam-pre-evaluation-template-04.xml

(I adjusted the dates to get past the date checks.)

The title is being picked up as

     Group

instead of as

  Preliminary Evaluation of RFC XXX "[PLACEHOLDER: INSERT TITLE HERE]",
for advancement from Draft Standard to Full Standard by the YAM Working
                                  Group

Obviously, the long lines that are part of the title are messing things 
up and the submission tool is only picking up the last line.

Given that the XML is also being uploaded, why aren't the title, 
abstract, and author info being extracted from there? I thought that was 
going to be one of the enhancements being put into the new I-D 
submission tool? That would avoid all issues with the issue-prone patterns.

     Tony Hansen

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 14 Mar 2011 12:54:35 +0100

(I changed the subject line to match the new issue)

> up and the submission tool is only picking up the last line.

Yes.

Emilio, I'd suggest changing the regex to require one or more blank
lines before and after the title, and making the first group explicitly
include all lines of the {1, 3} repeat (this is what messes up this
case).  Also, we should strip out newlines and extra space from the title.

Suggested patch:

12:44 ~/src/db/yaco/idsubmit/ietf/utils
henrik@merlot $ svn diff draft.py 
Index: draft.py
===================================================================
--- draft.py	(revision 2886)
+++ draft.py	(working copy)
@@ -575,11 +575,12 @@
     def get_title(self):
         if self._title:
             return self._title
-        title_re = re.compile('(.+\n){1,3}(\s+<?draft-\S+\s*\n)')
+        title_re = re.compile('(?:\n\s*\n\s*)((.+\n){1,3})(\s+<?draft-\S+\s*\n)\s*\n')
         match = title_re.search(self.pages[0])
         if match:
             title = match.group(1)
             title = title.strip()
+            title = re.sub('\s*\n\s*', ' ', title)
             self._title = title
             return self._title
         # unusual title extract

12:45 ~/src/db/yaco/idsubmit/ietf/utils
henrik@merlot $ 

> submission tool? That would avoid all issues with the issue-prone patterns.

Yes, but it's not part of this work order -- what we're trying to do with
this round is to replace the old tool as soon as possible, both to relieve
the pain of the old one, and to make it possible to migrate to the new
database schema.  There will more work done on the submission tool, to
cover _all_ of the requirements of RFC 4228, but that will come after we
have this round deployed.  Metadata extraction from XML files, if available,
is among the remaining 4228 requirements to be handled in the next round.

At least this has been the plan so far ...

Best,

	Henrik

---

From: "Emilio A. Sánchez López" <[email-masked]>
Date: Mon, 14 Mar 2011 15:49:42 +0100

Hi all,

> case).  Also, we should strip out newlines and extra space from the title.

    I do some testing with the patch and it seems to be perfect. Thank 
you Henrik.

    I have committed it [1] and applied in beta server.

    Best,

[1] http://wiki.tools.ietf.org/tools/ietfdb/ticket/617

-- 
Emilio A. Sánchez
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 14 Mar 2011 17:02:12 +0100

Hi Emilio,

> [1] http://wiki.tools.ietf.org/tools/ietfdb/ticket/617

Thanks!

Best,

	Henrik

---

From: Tony Hansen <[email-masked]>
Date: Mon, 14 Mar 2011 12:47:45 -0400

Much better -- I uploaded draft-ietf-yam-pre-evaluation-template-04 just 
fine now.

     Tony

---

From: Tony Hansen <[email-masked]>
Date: Mon, 14 Mar 2011 12:58:00 -0400

I uploaded a new version of draft-ietf-yam-pre-evaluation-template (-05) 
and it complains about an invalid version number, saying version 04 
expected. If I click on View Error, it shows an extract of the txt file 
with the draft name highlighted. However, it does not explain *why* it 
thinks that version number is in error and why version 04 is expected.

I changed the name of the file slightly and now it says that version 00 
is expected. However, it does not explain *why* it thinks that version 
number is in error and why version 00 is expected.

Another item: once the state has entered

     Status of the submission: Submitter Authentication Required

there appears to be no way to cancel a submission from the web without 
using information from the email message. This has the effect that if 
there's an issue with the email address that isn't caught until after 
clicking "Submit" on the form, it evidently cannot be corrected without 
operator intervention of some form via sending email to 
[email-masked].

     Tony Hansen

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 14 Mar 2011 18:53:42 +0100

> operator intervention of some form via sending email to 

Right.  It should be possible both to cancel a hung submission where
confirmation is impossible due to an email problem, and to request that
a new confirmation email be sent (with the appropriate rate limiting).

	Henrik

---

From: "Emilio A. Sánchez López" <[email-masked]>
Date: Thu, 17 Mar 2011 13:30:12 +0100

Hi.

    I updated the beta server with the new functionality [1]

    Now you only can edit metadata, post or cancel from an special url 
that contains a generated hash. You will reach this url after uploading 
your files so if you are the submitter you have the url in your browser 
history. This url could be share with other people.

    Remember that you can find the last submission of a draft using the 
search url [2]. But using this searcher you will go to a non privileged 
url where you can not cancel neither modify the submission.

    In this non privileged view you have a button to request the full 
url. If you click that button an email will be sent to draft authors and 
to the submitter (if he or she has filled its personal info) with the 
full access url.

    Now, from the full access url, you can cancel a submission that is 
waiting for submitter authentication.

    Secretariat users could perform any action from any of the status urls.

    By the way, we have to thank Henrik cause the hash url system is his 
idea.

[1] http://wiki.tools.ietf.org/tools/ietfdb/ticket/618
[2] http://beta.submit.yaco.es/submit/status/

-- 
Emilio A. Sánchez
[email-masked]