d59c64943d
* Handle single-word author names * Some i18n names, e.g., "शिला के.सी." have a dot at the end that is also part of the ASCII, e.g., "Shilaa Kesii." That trailing dot breaks extract_authors(). Avoid this issue by stripping the dot from the ASCII. * Honorifics need to be part of the extracted ASCII name (e.g., "Lady Garcia") * feat: stop supporting pre-tzaware migration database dumps. (#4782) * feat: stop supporting pre-tzaware migration database dumps. * chore: remove unnecessary env variable * chore: Use `codespell` to fix typos in comments. (#4794) First part of replacement of #4651 * feat: Only show IPR search form when not showing search results (#4793) * feat: Only show IPR search form when not showing search results Put it into a collapsible that is only expanded by default when not showing search results. Fixes #4569 * Don't use example target name * fix: Don't show reorder UI fixtures unless user can reorder (#4785) Fixes #4773 Co-authored-by: Robert Sparks <rjsparks@nostrum.com> * chore: Update deps and fix resulting HTML validation issues (#4790) * ci: add missing build matrix config for test-playwright-legacy step * Single-letter last names exist (e.g., "Carolina de la O") * Align regex with others * Fix extraction of very long author names * Need to be more general * Add comment * Also handle i18n names with trailing semicolons * Name suffixes need to be part of the extracted author names * Handle i18n names with embedded commas Co-authored-by: Robert Sparks <rjsparks@nostrum.com> Co-authored-by: Nicolas Giard <github@ngpixel.com>
247 lines
6.9 KiB
Plaintext
247 lines
6.9 KiB
Plaintext
|
||
|
||
|
||
|
||
Network Working Group %(firstpagename)37s
|
||
Internet-Draft Test Centre Inc.
|
||
Intended status: Informational %(month)s %(year)s
|
||
Expires: %(expiration)s
|
||
|
||
|
||
%(title)s
|
||
%(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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Name Expires %(expiration)s [Page 1]
|
||
|
||
Internet-Draft Testing Tests %(month)s %(year)s
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Yang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
3. JSON example . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 2
|
||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2
|
||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 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. JSON example
|
||
|
||
The JSON object should look like this:
|
||
|
||
{
|
||
"test": 1234
|
||
}
|
||
|
||
4. Security Considerations
|
||
|
||
There are none.
|
||
|
||
5. IANA Considerations
|
||
|
||
No new registrations for IANA.
|
||
|
||
[RFC8175] is mentioned here in order to give the reference
|
||
classification code a chance to mess up.
|
||
|
||
|
||
6. References
|
||
|
||
6.1. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119,
|
||
DOI 10.17487/RFC2119, March 1997,
|
||
<https://www.rfc-editor.org/info/rfc2119>.
|
||
|
||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
|
||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
|
||
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
|
||
|
||
6.2. Informative References
|
||
|
||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
|
||
Writing an IANA Considerations Section in RFCs", BCP 26,
|
||
RFC 8126, DOI 10.17487/RFC8126, June 2017,
|
||
<https://www.rfc-editor.org/info/rfc8126>.
|
||
|
||
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
|
||
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
|
||
DOI 10.17487/RFC8175, June 2017,
|
||
<https://www.rfc-editor.org/info/rfc8175>.
|
||
|
||
Author's Address
|
||
|
||
%(author)s
|
||
Test Centre Inc.
|
||
42 Some Road
|
||
Some Where 12345
|
||
UK
|
||
|
||
Email: %(email)s
|
||
|
||
|
||
|
||
Appendix A. Comments
|
||
|
||
[RFC8174] is mentioned here just to give the reference classification
|
||
code a chance to mess up.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Name Expires %(expiration)s [Page 2]
|