Add a note about PREs, update NIP 36 to point to NIP 32

2 files changed, 19 insertions, 3 deletions

diff --git a/32.md b/32.md
index 1939555..b572c13 100644
--- a/32.md
+++ b/32.md
@@ -23,9 +23,13 @@ or topics respectively. As with NIP-01, a relay hint SHOULD be included when usi
 Label Tag
 ----
 
-This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples:
+This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace.
+A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature
+external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD
+ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples:
 
-Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
+Namespaces starting with `#` indicate that the label target should be associated with the label's value.
+This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
 
 - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied.
 - `["l", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
@@ -164,3 +168,10 @@ Publishers can self-label by adding `l` tags to their own non-1985 events.
   ...
 }
 ```
+
+Other Notes
+-----------
+
+When using this NIP to bulk-label many targets at once, events may be deleted and a replacement
+may be published. We have opted not to use parameterizable/replaceable events for this due to the
+complexity in coming up with a standard `d` tag.
diff --git a/36.md b/36.md
index 1223e53..379d40a 100644
--- a/36.md
+++ b/36.md
@@ -9,12 +9,15 @@ Sensitive Content / Content Warning
 The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown.
 Clients can hide the content until the user acts on it.
 
+`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` namespace to support
+further qualification and querying.
+
 #### Spec
 
 ```
 tag: content-warning
 options:
- - [reason]: optional  
+ - [reason]: optional
 ```
 
 #### Example
@@ -26,6 +29,8 @@ options:
     "kind": 1,
     "tags": [
       ["t", "hastag"],
+      ["L", "content-warning"],
+      ["l", "reason", "content-warning"],
       ["content-warning", "reason"] /* reason is optional */
     ],
     "content": "sensitive content with #hastag\n",