From 5e701b07d02f72f063903b9be60b8ab9248ecb60 Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Sun, 17 Mar 2024 00:30:04 +0000
Subject: [PATCH] Script updating archive at 2024-03-17T00:30:04Z. [ci skip]

---
 archive.json | 56 +++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/archive.json b/archive.json
index b8aa373..92e1140 100644
--- a/archive.json
+++ b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2024-03-14T00:27:03.538982+00:00",
+  "timestamp": "2024-03-17T00:30:02.687780+00:00",
   "repo": "ietf-wg-scitt/draft-ietf-scitt-scrapi",
   "labels": [
     {
@@ -62,9 +62,17 @@
       "labels": [],
       "body": "Would be great to be able to return an object in addition to or instead of a string for errors. Or allow for other properties which would be fully content-typeable to a custom response object within the error response on claim insert failure.\r\n\r\nLack of this prevents an automated conversation to resolve issues with claim insertion. Human readable strings are great, but ideally a human doesn't even get involved and machines can auto remediate issues due to detailed failure reasoning. This way the a human readable string might only be needed after a failed machine driven insert conversation (more than one call response).\r\n\r\n- References\r\n  - https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/issues/4\r\n    - https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/62",
       "createdAt": "2024-03-11T01:34:22Z",
-      "updatedAt": "2024-03-11T01:34:49Z",
+      "updatedAt": "2024-03-15T23:38:21Z",
       "closedAt": null,
-      "comments": []
+      "comments": [
+        {
+          "author": "aj-stein-nist",
+          "authorAssociation": "NONE",
+          "body": "I do agree but it seems per the spec we are following [RFC7807](https://www.rfc-editor.org/rfc/rfc7807#page-7) and they have this to say about our desired change in this request.\r\n\r\n   Consumers SHOULD NOT parse the \"detail\" member for information;\r\n   extensions are more suitable and less error-prone ways to obtain such\r\n   information.\r\n\r\nI am looking more into these mysterious \"extensions\" mentioned in this spec. ",
+          "createdAt": "2024-03-15T23:38:20Z",
+          "updatedAt": "2024-03-15T23:38:20Z"
+        }
+      ]
     },
     {
       "number": 3,
@@ -81,6 +89,22 @@
       "updatedAt": "2024-03-12T19:06:56Z",
       "closedAt": null,
       "comments": []
+    },
+    {
+      "number": 4,
+      "id": "I_kwDOLJjbks6CguBZ",
+      "title": "Test suite",
+      "url": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-scrapi/issues/4",
+      "state": "OPEN",
+      "author": "aj-stein-nist",
+      "authorAssociation": "NONE",
+      "assignees": [],
+      "labels": [],
+      "body": "I am not sure this is within the scope of the formal working group or better as an \"outside\" community effort, but with the relocation of this draft into the ietf-wg-scitt org and its upload to datatracker, have we considered having a test suite with sample artifacts, signed statements, and transparent statements that conform to the API spec here as a test harness of sorts? I have seen *some* IETF and other standard bodies groups making such test suites. I am opening this issue here to gauge interest and determine if making it \"inline in this repo\" is within scope or not.",
+      "createdAt": "2024-03-15T23:42:41Z",
+      "updatedAt": "2024-03-15T23:42:41Z",
+      "closedAt": null,
+      "comments": []
     }
   ],
   "pulls": [
@@ -166,6 +190,32 @@
           "comments": []
         }
       ]
+    },
+    {
+      "number": 5,
+      "id": "PR_kwDOLJjbks5p2OWP",
+      "title": "Add Security Considerations consistent with RFC 3552",
+      "url": "https://github.com/ietf-wg-scitt/draft-ietf-scitt-scrapi/pull/5",
+      "state": "OPEN",
+      "author": "JAG-UK",
+      "authorAssociation": "NONE",
+      "assignees": [],
+      "labels": [],
+      "body": "Hackathon entry for 119, fill in required elements from RFC 3552",
+      "createdAt": "2024-03-17T00:26:38Z",
+      "updatedAt": "2024-03-17T00:26:48Z",
+      "baseRepository": "ietf-wg-scitt/draft-ietf-scitt-scrapi",
+      "baseRefName": "main",
+      "baseRefOid": "94b8e8d94e2f96ac2a76c28d7a6478d367cddff8",
+      "headRepository": "ietf-wg-scitt/draft-ietf-scitt-scrapi",
+      "headRefName": "dev/jag-uk/security-considerations-section",
+      "headRefOid": "2726176c9dd943f60d80966819c7881e81e554fb",
+      "closedAt": null,
+      "mergedAt": null,
+      "mergedBy": null,
+      "mergeCommit": null,
+      "comments": [],
+      "reviews": []
     }
   ]
 }
\ No newline at end of file