feat: define application/lws+json as default container media type

Define application/lws+json as the default media type for container
representations, equivalent to application/ld+json with the LWS
profile. Servers must return the same payload for application/lws+json,
application/ld+json, and application/json — only the Content-Type
header varies. Update IANA considerations with profile parameter,
security considerations, and equivalence note following the Activity
Streams precedent.

Author: laurensdeb

lws10-core/IANA-Considerations.html

@@ -45,30 +45,55 @@ <h3>OAuth Authorization Server Metadata Registry</h3>
 </section>
 
 <section id="iana-media-type-registry">
-  <h3>Media Type Registry</h3>
+  <h3>The <code>application/lws+json</code> Media Type</h3>
 
   <p>
-    This specification registers the <code>application/lws+json</code> media type for identifying documents conforming to the
-    linked web storage document format.
+    This specification registers the <code>application/lws+json</code> media type specifically for identifying documents
+    conforming to the Linked Web Storage container format.
   </p>
 
   <ul>
     <li>
-      Type Name: application
+      Type name: application
     </li>
     <li>
-      Subtype Name: lws+json
+      Subtype name: lws+json
     </li>
     <li>
-      Required parameter: None
+      Required parameters: None
+    </li>
+    <li>
+      Optional parameters: <b>profile</b>: The profile parameter for the <code>application/lws+json</code> media type allows
+      one or more profile URIs to be specified. These profile URIs have the identifier semantics defined in [[RFC6906]].
+      The "profile" media type parameter MUST be quoted. It contains a non-empty list of space-separated URIs (the profile URIs).
+      <pre>
+profile-param = "profile=" profile-value
+profile-value = &lt;"&gt; profile-URI 0*( 1*SP profile-URI ) &lt;"&gt;
+profile-URI   = URI
+      </pre>
+      The "URI" in the above grammar refers to the "URI" as defined in Section 3 of [[RFC3986]].
     </li>
     <li>
       Encoding considerations: Resources that use the <code>application/lws+json</code> media type are required to conform to
       all of the requirements for the <code>application/json</code> media type and are therefore subject to the same encoding
       considerations specified in Section 11 of [[RFC8259]].
     </li>
     <li>
-      Contact: W3C Linked Web Storage Working Group public-lws-wg@w3.org
+      Security considerations: As defined in this specification.
+    </li>
+    <li>
+      Contact: W3C Linked Web Storage Working Group &lt;public-lws-wg@w3.org&gt;
     </li>
   </ul>
+
+  <p>
+    Note that while the Linked Web Storage format uses JSON-LD conventions, there are a number of constraints and additional
+    requirements for LWS implementations that justify the use of a specific media type.
+  </p>
+
+  <p>
+    Because LWS containers can be considered a restricted profile of JSON-LD, implementations SHOULD consider the
+    <code>application/ld+json; profile="https://www.w3.org/ns/lws/v1"</code> media type as equivalent to
+    <code>application/lws+json</code>.
+  </p>
 </section>

lws10-core/Operations/read-resource.md

@@ -51,7 +51,7 @@ Accept: application/ld+json
 Assuming the container exists and the client has access:
 ```
 HTTP/1.1 200 OK
-Content-Type: application/ld+json; profile="https://www.w3.org/ns/lws/v1"
+Content-Type: application/lws+json
 ETag: "container-etag-789"
 Link: </alice/notes/.meta>; rel="linkset"; type="application/linkset+json"
 Link: </alice/>; rel="up"

lws10-core/Operations/restbinding.md

@@ -1,3 +1,3 @@
 For each core operation (create, read, update, delete), we describe the HTTP method(s) to use, required headers or special considerations (including concurrency controls via ETags, content negotiation, and pagination for container listings), and what the server should do and return. Standard HTTP status codes are used to indicate outcomes with additional mappings for scenarios such as quota exceeded (507 Insufficient Storage) or precondition failures (412 Precondition Failed). The binding tries to adhere to HTTP/1.1 and relevant RFCs (such as [[!RFC7231]] for HTTP semantics, [[!RFC7233]] for range requests, [[!RFC5789]] for PATCH, [[!RFC8288]] for Web Linking, and [[!RFC9264]] for Link Sets) so that it integrates naturally with web standards. Discoverability is emphasized through mechanisms like Link headers and WWW-Authenticate headers on 401 responses, avoiding hardcoded URI locations. Metadata integration is required across operations, ensuring atomicity and use of Link Sets for server-managed and user-managed properties.
 
-**Note:** As all examples in this specifications, examples given in this section (HTTP request and response snippets) are **non-normative**, meant to illustrate typical usage. The actual requirements are stated in the descriptive text and tables. Also, while this binding covers HTTP (as the initial target protocol), the LWS operations could in principle be bound to other protocols in the future. Servers SHOULD support content negotiation for formats like JSON-LD (with normative contexts for containers) and Turtle, using the LWS media type `application/ld+json; profile="https://www.w3.org/ns/lws/v1"` for container representations.
+**Note:** As all examples in this specifications, examples given in this section (HTTP request and response snippets) are **non-normative**, meant to illustrate typical usage. The actual requirements are stated in the descriptive text and tables. Also, while this binding covers HTTP (as the initial target protocol), the LWS operations could in principle be bound to other protocols in the future. Servers MUST support content negotiation for `application/lws+json`, `application/ld+json`, and `application/json` for container representations (see [Container Media Type](#container-media-type)). Servers MAY additionally support formats like Turtle.

lws10-core/container-media-type.md

@@ -1,11 +1,23 @@
 ### Container Media Type
 
-Container representations MUST be served using the following media type:
+The default media type for LWS container representations is:
 
 ```
-application/ld+json; profile="https://www.w3.org/ns/lws/v1"
+application/lws+json
 ```
 
-This media type indicates a JSON-LD document conforming to the LWS container vocabulary. Servers MUST use this media type in the `Content-Type` header when responding to requests for container resources. Clients MUST use this media type in the `Content-Type` header when creating new containers.
+While LWS container representations use JSON-LD conventions, the constraints and requirements for LWS justify the use of a specific media type. Because LWS containers can be considered a restricted profile of JSON-LD, implementations SHOULD consider the `application/ld+json; profile="https://www.w3.org/ns/lws/v1"` media type as equivalent to `application/lws+json`.
+
+#### Content Negotiation
+
+Servers MUST support content negotiation for container representations. The response payload MUST be identical regardless of the requested media type — only the `Content-Type` response header varies:
+
+- If a client requests `application/lws+json`, the server MUST respond with `Content-Type: application/lws+json`.
+- If a client requests `application/ld+json`, the server MUST respond with `Content-Type: application/ld+json`.
+- If a client requests `application/json`, the server MUST respond with `Content-Type: application/json`.
+
+In all three cases, the response body is the same JSON-LD document conforming to the LWS container vocabulary. Servers are free to support additional media types (e.g., `text/turtle`) through content negotiation.
+
+#### Processing as JSON
 
 Although container representations are valid JSON-LD, clients MAY process them as plain JSON without invoking a full JSON-LD processor. The `@context` property in the representation provides the mapping to the LWS vocabulary, but all property names used in container representations are short, predictable tokens (e.g., `id`, `type`, `items`, `totalItems`) that can be consumed directly as JSON keys.