a0f6cdb661
* fix: Use relative URL for submission status link * refactor: Refactor/rename process_uploaded_submission async task * feat: Add async task to process but not accept a submission * feat: Replace upload_submission() with an async implementation (WIP) * fix: Do not put Submission in "uploaded" state if an error occured * refactor: Improve text/XML draft processing flow * feat: Extract authors from text in async processing * fix: Fix call signatures and abort submission on failed validation * feat: Validate submission name format * fix: Correctly validate emails from text submission * fix: Clean up submission validation * fix: Better display errors on upload_submission page * feat: Reload submission status page when awaiting validation * test: Fix call signatures; remove unused imports * chore: Add type hint * test: Update tests to match renamed task * fix: Fix typo in error message * test: Fix failing Api- and AsyncSubmissionTests * Rename process_uploaded_submission to process_and_accept_... * Remove outdated tests Does not yet test new behavior. * refactor: Break up submission_file() helper * test: Refactor tests to run the async processing (wip) * test: Drop test of bad PDF submission The PDF submission field was removed, so no need to test it. * test: Update more tests * test: Bring back create_and_post_submission() and fix more tests * fix: Drop to manual, don't cancel, on revision inconsistency Fixes remaining failing SubmitTest tests * style: Restyle upload_submission() with black * test: Verify that async submission processing is invoked on upload * test: Bring back old do_submission and fix tests Properly separating the upload and async processing stages of submission is a bigger refactoring than will fit right now. This better exercises the submission pipeline. * fix: Accept only XML for API submissions * test: Test submission processing utilities * feat: Improve status display for "validating" submissions * chore: Remove obsolete code * test: Update test to match amended text --------- Co-authored-by: Robert Sparks <rjsparks@nostrum.com>
204 lines
5.5 KiB
Plaintext
204 lines
5.5 KiB
Plaintext
|
||
|
||
|
||
|
||
Network Working Group %(initials)s %(surname)s
|
||
Internet-Draft Test Centre Inc.
|
||
Intended status: Informational %(month)s %(year)s
|
||
Expires: %(expiration)s
|
||
|
||
|
||
Testing Tests
|
||
%(name)s
|
||
|
||
Abstract
|
||
|
||
This document describes how to test tests.
|
||
|
||
Status of This Memo
|
||
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF). Note that other groups may also distribute
|
||
working documents as Internet-Drafts. The list of current Internet-
|
||
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
This Internet-Draft will expire on %(expiration)s.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) %(year)s IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
%(surname)s Expires %(expiration)s [Page 1]
|
||
|
||
Internet-Draft Testing Tests %(month)s %(year)s
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Security Considerations . . . . . . . . . . . . . . . . . . . 2
|
||
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
|
||
1. Introduction
|
||
|
||
This document describes a protocol for testing tests.
|
||
|
||
2. Yang
|
||
|
||
<CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang"
|
||
|
||
module ietf-yang-metadata {
|
||
|
||
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";
|
||
|
||
prefix "md";
|
||
|
||
organization
|
||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
|
||
|
||
contact
|
||
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
|
||
|
||
WG List: <mailto:netmod@ietf.org>
|
||
|
||
WG Chair: Lou Berger
|
||
<mailto:lberger@labn.net>
|
||
|
||
WG Chair: Kent Watsen
|
||
<mailto:kwatsen@juniper.net>
|
||
|
||
Editor: Ladislav Lhotka
|
||
<mailto:lhotka@nic.cz>";
|
||
|
||
description
|
||
"This YANG module defines an 'extension' statement that allows
|
||
for defining metadata annotations.
|
||
|
||
Copyright (c) 2016 IETF Trust and the persons identified as
|
||
authors of the code. All rights reserved.
|
||
|
||
Redistribution and use in source and binary forms, with or
|
||
without modification, is permitted pursuant to, and subject to
|
||
the license terms contained in, the Simplified BSD License set
|
||
forth in Section 4.c of the IETF Trust's Legal Provisions
|
||
Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info).
|
||
|
||
This version of this YANG module is part of RFC 7952
|
||
(http://www.rfc-editor.org/info/rfc7952); see the RFC itself
|
||
for full legal notices.";
|
||
|
||
revision 2016-08-05 {
|
||
description
|
||
"Initial revision.";
|
||
reference
|
||
"RFC 7952: Defining and Using Metadata with YANG";
|
||
}
|
||
|
||
extension annotation {
|
||
argument name;
|
||
description
|
||
"This extension allows for defining metadata annotations in
|
||
YANG modules. The 'md:annotation' statement can appear only
|
||
at the top level of a YANG module or submodule, i.e., it
|
||
becomes a new alternative in the ABNF production rule for
|
||
'body-stmts' (Section 14 in RFC 7950).
|
||
|
||
The argument of the 'md:annotation' statement defines the name
|
||
of the annotation. Syntactically, it is a YANG identifier as
|
||
defined in Section 6.2 of RFC 7950.
|
||
|
||
An annotation defined with this 'extension' statement inherits
|
||
the namespace and other context from the YANG module in which
|
||
it is defined.
|
||
|
||
The data type of the annotation value is specified in the same
|
||
way as for a leaf data node using the 'type' statement.
|
||
|
||
The semantics of the annotation and other documentation can be
|
||
specified using the following standard YANG substatements (all
|
||
are optional): 'description', 'if-feature', 'reference',
|
||
'status', and 'units'.
|
||
|
||
A server announces support for a particular annotation by
|
||
including the module in which the annotation is defined among
|
||
the advertised YANG modules, e.g., in a NETCONF <hello>
|
||
message or in the YANG library (RFC 7950). The annotation can
|
||
then be attached to any instance of a data node defined in any
|
||
YANG module that is advertised by the server.
|
||
|
||
XML encoding and JSON encoding of annotations are defined in
|
||
RFC 7952.";
|
||
}
|
||
}
|
||
|
||
<CODE ENDS>
|
||
|
||
3. Security Considerations
|
||
|
||
There are none.
|
||
|
||
4. IANA Considerations
|
||
|
||
No new registrations for IANA.
|
||
|
||
Author's Address
|
||
|
||
%(author)s
|
||
Test Centre Inc.
|
||
42 Some Road
|
||
Some Where 12345
|
||
UK
|
||
|
||
Email: %(email)s
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
%(surname)s Expires %(expiration)s [Page 2]
|