-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathI-D-Profile-Negotiation.xml
805 lines (684 loc) · 39.7 KB
/
I-D-Profile-Negotiation.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3236 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3236.xml">
<!ENTITY RFC3870 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3870.xml">
<!ENTITY RFC4452 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4452.xml">
<!ENTITY RFC5234 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5988 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY RFC6838 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY RFC6906 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6906.xml">
<!ENTITY RFC7231 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7240 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7240.xml">
<!ENTITY RFC8141 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml">
<!ENTITY RFC8288 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml">
<!ENTITY RFC9110 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml">
<!ENTITY RFC9112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml">
<!ENTITY RFC9264 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9264.xml">
<!ENTITY SHACL SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.REC-shacl-20170720.xml">
<!ENTITY XSD SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.REC-xmlschema11-1-20120405.xml">
<!ENTITY I-D.nottingham-link-hint SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nottingham-link-hint.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" docName="draft-svensson-profiled-representations-01" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Handling Profiled Representations">Indicating, Discovering, Negotiating, and Writing Profiled Representations</title>
<author fullname="Lars G. Svensson" initials="L.G." surname="Svensson">
<address>
<email>[email protected]</email>
<uri>https://orcid.org/0000-0002-8714-9718</uri>
</address>
</author>
<author fullname="Ruben Verborgh" initials="R." surname="Verborgh">
<organization>Ghent University – imec</organization>
<address>
<postal>
<street>Sint-Pietersnieuwstraat 41</street>
<code>9000</code>
<city>Ghent</city>
<region/>
<country>Belgium</country>
</postal>
<phone>+32 9 331 49 10</phone>
<email>[email protected]</email>
<uri>https://ruben.verborgh.org/</uri>
</address>
</author>
<author initials="H." surname="Van de Sompel" fullname="Herbert Van de Sompel">
<organization>Data Archiving and Networked Services</organization>
<address>
<postal>
<street>Anna van Saksenlaan 51</street>
<code>2593 HW</code>
<city>The Hague</city>
<region/>
<country>Netherlands</country>
</postal>
<email>[email protected]</email>
<uri>https://orcid.org/0000-0002-0715-6126</uri>
</address>
</author>
<date month="December" year="2024"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>This document details approaches for enriching HTTP interactions with information pertaining to
the profiles to which resource representations conform.
It surveys approaches that were introduced to indicate the profile of a resource representation,
and to make representations that conform to a profile discoverable.
It introduces a generally applicable approach to negotiate for a resource representation that conforms to a profile preferred
by a user agent. That approach leverages the existing content negotiation mechanism but applies it to the profile dimension to which
it was previously not applied. The document also shows how a server can convey which profiled representations it is able to
accept from a user agent.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Any given web resource can typically be represented in a variety of ways. For example, the same information could be rendered according to different media types,
say, as XML or JSON. But in many cases, variations in representation other than those inherent to a given media type are also possible. For example, the
same structured data could be rendered in XML according to different <xref target="W3C.REC-xmlschema11-1-20120405">XML Schema</xref>.
Or the same RDF graph could be expressed on the basis of different vocabularies.
</t>
<t>
This dimension of variability regarding representations that goes beyond media types has been acknowledged for quite some time. For example, in 2000, the Dublin Core
Metadata Initiative (DCMI) introduced "Application Profiles" to explicitly acknowledge that the same metadata can be represented in various ways and defined them as "schemas which consist of data
elements drawn from one or more namespaces, combined together by implementers, and optimised for a particular local application" <xref target="HeeryAndPatel"/>.
</t>
<section title="Terminology">
<t>Inspired by the term used in <xref target="RFC6906"/> to refer to this extra dimension of variability, this document uses the term "profile" to mean a description of
structural and/or semantic constraints on representations of resources that apply
in addition to the constraints inherently indicated by their MIME type:</t>
<t><list style="symbols">
<t>Profiles can be dependent on a media type. For example, this is the case for XML, with constraints being expressed using an XML Schema.
This is also the case for JSON that offers a wide range of options regarding the use of tree structure, keys, and value types.
In these cases, the meaning of the term "profile" intended by this document coincides with the use of the same term in <xref target="RFC6906"/>.</t>
<t>Profiles can be independent of media type. For example, this is the case for RDF graphs that can be rendered according to various media types,
while constraints can be expressed in a manner that is independent of media type, among others, using <xref target="W3C.REC-shacl-20170720">SHACL</xref>.
In these cases, the meaning of the term "profile" intended by this document is a slight extension of the one intended by <xref target="RFC6906"/>.</t>
</list></t>
</section>
<section title="Purpose" anchor="why">
<t>When it comes to HTTP interactions, profiles have received little attention despite their de facto existence and
the added-value they can bring for building rich applications. Such applications benefit from knowledge regarding the nature of a representation
that a client obtains from a server, that a client sends to a server, and that a server is willing to accept from a client,
beyond what is conveyed by the representation's MIME type.
These applications are also be helped by an ability to discover representations rendered according to a profile they can handle, or,
optimally, an ability to explicitly request a rendering according to a preferred profile.
</t>
<t>A common approach to handle profiles is to register them as a media type, dedicated to the combination of an actual media type
and a profile of it. Media types that illustrate this approach include "application/activity+json", "application/calendar+json", and "application/calendar+xml.
This approach allows conveying all necessary profile information in HTTP interactions, e.g. using the "Accept" and "Content-Type" HTTP headers
and the "type" attribute for web links. As such it supports indicating, discovering, and content negotiating (in the media type dimension) for profiled representations.
This registration-based approach may be feasible for
profiles that are expected to be very widely used but is not practical in case support for many different profiles is required.
Also, the "calendar" examples illustrate
that the registration-based approach is not ideal when a profile applies to multiple media types.
And, the "activity" example illustrates that
the approach supports indicating what the major ingredient of a profiled representation is (i.e. the ActivityStreams Vocabulary) but becomes problematic
when indications are also needed regarding additional vocabularies used in representations.
</t>
<t>Another approach to handle profiles leverages the ability provided by <xref target="RFC6838"/> to register parameters when registering a media type.
Some media types have used this capability to register an attribute dedicated to conveying profiles of the media type. For example, for "application/ld+json"
the "profile" parameter has been registered for this purpose. The approach provides flexibility for handling many profiles,
including ones that are not yet known when registering the media type.
It also supports indicating, discovering, and content negotiating (in the media type dimension) for profiled representations using common approaches.
But the approach remains problematic because it ties profile information to a media type, depends on registering a parameter to convey profile information
when registering a new media type, and, realistically, on the registration of the same parameter name (i.e. "profile" as suggested in <xref target="RFC6906"/>)
for all media types for which registrants deem that conveying profile information is important.
Additionaly, <xref target="RFC6838"/> discourages registering parameters for previously registered media types, making it highly questionable that a uniform attribute
to convey profile information across all media types could retroactively be defined.</t>
<t>Recognizing the importance of profiles and the problems with the aforementioned approaches to handle them,
specifications have started to introduce alternative approaches to express information about
resource representation profiles in HTTP interactions:</t>
<t><list style="symbols">
<t><xref target="RFC6906"/> introduces the "profile" link relation type that is generally
applicable for indicating the profile of a resource representation that is sent by a client to a server or by a server to a client.
</t>
<t><xref target="I-D.nottingham-link-hint"/> introduces a capability to make profiled representations discoverable via web links by using the "formats"
attribute to express the profile of a linked resource.
</t>
</list></t>
<t><xref target="Indicating"/> and <xref target="Discovering"/>
provide a concise overview of the approaches introduced by <xref target="RFC6906"/> and <xref target="I-D.nottingham-link-hint"/>,
to respectively indicate and discover the profile of resource representations.
<xref target="Negotiating"/> specifies a generally applicable approach to negotiate for representations that conform to a profile preferred by a user agent.
<xref target="Writing"/> shows how servers can convey which profiled representations they are able to accept from user agents.
</t>
</section>
<section title="Notational Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This specification uses the terms "link context" and "link target" as defined in <xref target="RFC8288"/>.
These terms respectively correspond with "Context IRI" and "Target IRI" as used in <xref target="RFC5988"/>.
Although defined as IRIs, in common scenarios they are also URIs.</t>
<t>In the examples provided in this document, links in the HTTP "Link" header are shown on separate lines in order to improve readability.
Note, however, that as per Section 3.2 of <xref target="RFC9112"/>, line breaks are not allowed in values for HTTP headers; only whitespaces and
tabs are supported as seperators.
</t>
</section>
</section>
<section title="Indicating Profiled Representations" anchor="Indicating">
<t>As per <xref target="RFC6906"/>, a web link with a "profile" link relation type can be used to
indicate the profile of a representation that is exchanged in HTTP interactions. <xref target="request_SI1"/> shows a client requesting a
representation from a server and <xref target="response_SI1"/> shows the server responding. The response includes a "Link" header
(<xref target="RFC8288"/>) that contains a link with the "profile" relation type.
The link target <http://purl.org/dc/terms/> indicates the profile of
the response body (not shown).
</t>
<t><xref target="request_UI1"/> shows a client submitting a representation to a server,
using the same approach to express the profile to which that representation conforms.
<xref target="Writing"/> describes how a server can convey the profiles it supports
for representations that are submitted by a user agent.
</t>
<figure title="Client requests a representation" align="center" anchor="request_SI1">
<artwork align="left"><![CDATA[
GET /some/resource HTTP/1.1
Host: example.org
Connection: close
]]>
</artwork>
</figure>
<figure title="Server indicates the profile of the returned representation" align="center" anchor="response_SI1">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/xml ; charset=utf-8
Link: <http://purl.org/dc/terms/>; rel="profile"
Content-Length: 23364
Connection: close
...
]]>
</artwork>
</figure>
<figure title="Client indicates the profile of a representation submitted to a server" align="center" anchor="request_UI1">
<artwork align="left"><![CDATA[
PUT /some/resource HTTP/1.1
Host: example.org
Content-Type: application/xml ; charset=utf-8
Link: <http://purl.org/dc/terms/>; rel="profile"
Content-Length: 23364
Connection: close
...
]]>
</artwork>
</figure>
<t>In some cases organisations use separate servers to perform content negotiation and to deliver resources,
e. g. when static content is served through content delivery networks.
The servers that perform the content negotiation interact with the client requesting the resource
and then typically refer to the correct representation using a 303 redirect.
In those cases the servers that deliver the representations are not profile aware
and thus cannot add the appropriate "Link" headers to the response.
Instead the server performing the negotiation will have to supply that information.
This is done by adding an "anchor" attribute pointing to the representation the link header refers to.
<xref target="response_RI1"/> shows the response to a <xref target="request_SI1"/>
where the server performing the negotiation redirects the client to the resource specified in the
"Location" header and by using the same URI in the "anchor" attribute of the "Link" header
indicates that the information in the "Link" header does not apply to this response
but to the resource redirected to.
</t>
<figure title="Server indicates the profile of the representation referred to in the 'Location' header" align="center" anchor="response_RI1">
<artwork align="left"><![CDATA[
HTTP/1.1 303 See other
Location: https://static.example.org/other/resource
Link: <http://purl.org/dc/terms/>; rel="profile"
; anchor="https://static.example.org/other/resource"
...
]]>
</artwork>
</figure>
</section>
<section title="Discovering Profiled Representations" anchor="Discovering">
<t>The link hints capability introduced in <xref target="I-D.nottingham-link-hint"/>, can be leveraged by a server to make profiled representations discoverable by
including a "formats" attribute on web links. <xref target="response_SI2"/> shows a response to the client request of
<xref target="request_SI1"/> in which the server uses this technique. The "Link" header indicates the profile of the returned representation
but also points at two alternative representations, each of which conforms to another profile.
</t>
<figure title="Server makes profiled representations discoverable" align="center" anchor="response_SI2">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/xml
Link: <http://purl.org/dc/terms/> ; rel="profile" ,
</some/other_resource_1>
; rel="alternate" ; type="application/xml"
; formats="http://example.org/our_internal_xml_profile" ,
</some/other_resource_2>
; rel="alternate"
; formats="http://example.org/our_community_profile"
Content-Length: 23364
Connection: close
...
]]>
</artwork>
</figure>
</section>
<section title="Negotiating for Profiled Representations" anchor="Negotiating">
<t><xref target="why"/> describes two approaches for conveying profile information in HTTP interactions that make
it possible to negotiate for profiled representations by applying content negotiation in the media type dimension.
It also indicates the restricted applicability of these approaches, in both cases a result of their direct dependence on the
media type registration process.
</t>
<t>
This section describes an approach that applies content negotiation in a dimension that it was previously not applied to.
The profile negotiation approach introduced here is generally applicable for
resource representations, irrespective of media type. These are its core aspects:
</t>
<t><list style="symbols">
<t>In order to allow a user agent to inform a server about its preferences regarding profiles for resource representations,
the "Accept-Profile" HTTP header introduced here is used. A user agent can specify several profiles and use quality indicators (q-values)
to indicate preferences.
</t>
<t>In order to allow a server to express its support for profile negotiation
the "Vary" HTTP header is used, in this case, with the "Accept-Profile" value.</t>
<t>In order to allow a server to convey the profile of a representation delivered to a user agent,
rather than introducing a server-side counterpart to the client-side "Accept-Profile" header,
the existing
"profile" link approach introduced by <xref target="RFC6906"/> is used. If a representation conforms to multiple profiles, a distinct "profile"
link is used per profile; the order in which these links are provided has no relevance.
</t>
<t>In order to allow a server to convey the profiles it supports, web links
with the "formats" link hint introduced in <xref target="I-D.nottingham-link-hint"/> are used to convey the profiles of the link target
resources. This approach uniformely applies to reponses to HTTP HEAD/GET/PUT/POST/PATCH.
</t>
<t>Throughout the profile negotiation approach, a profile MUST be referred to by a URI. This is the case for the content of the "Accept-Profile" HTTP header,
for the target of web links with the "profile" link relation, and
for the content of the "formats" link hint for web links.
</t>
</list></t>
<section title="Profile Negotiation Details">
<t>Profile negotiation uses the content negotiation processes described in
<xref target="RFC7231">Section 3.4 of RFC 7231</xref> but applies them to the profile dimension.
Both proactive negotiation and reactive negotiation for profiles can be supported by servers.
Both are described in more detail in the remainder of this section.
</t>
<t>
In profile negotiation, a profile MUST be referred to by a URI that, from here onwards, is named a profile URI.
If the profile URI is dereferencable it SHOULD lead to a document that details the profile. If the profile URI
is not dereferencable (e.g. a <xref target="RFC8141">URN</xref> or an <xref target="RFC4452">info-URI</xref>)
facilities SHOULD be available to allow user agents and servers to understand their meaning, e.g. community registries of profiles.
</t>
<section title="Proactive Profile Negotiation" anchor="proconneg">
<t>In proactive profile negotiation, the user agent uses the
"Accept-Profile" HTTP header to inform the server about the agent's preference
regarding profiles to be used for representing a resource in the server's response.
In case a user agent wants to express a preference for a single profile, the value of the header is that
profile's URI. In case a user agent wants to express a preference for multiple profiles, the value of the header is
a list containing each profile's URI, seperated by commas. Alternatively, multiple "Accept-Profile" HTTP headers can be used,
each conveying a single profile URI. Quality indicators (q-values) MAY be used to rank profile preferences.
The order in which profile URIs are conveyed or the duplicate mentioning of a same profile URI
MUST NOT be interpreted as significant.
</t>
<t>A server that supports proactive profile negotiation for the resource that a user agent
interacts with:
</t>
<t><list style="symbols">
<t>MUST include a "Vary" HTTP header containing the value "accept-profile" in its response to the user agent.
</t>
<t>MUST include a "Link" HTTP header containing a link with the "profile" relation type that has as link target the profile URI
of the resource representation returned to the user agent. In case the representation conforms to additional profiles known
to the server, such a "profile" link SHOULD be included for each.
</t>
<t>SHOULD convey the availability of alternate profiled representations of the resource by using the
link hint approach described in <xref target="reconneg"/>.
</t>
</list>
</t>
<t>These requirements for servers that support proactive profile negotiation also apply when:</t>
<t><list style="symbols">
<t>The user agent expressed a profile preference in its request by using an "Accept-Profile" header but the server
cannot return a representation that conforms to a preferred profile.
</t>
<t>The user agent did not express a profile preference using an "Accept-Profile" header in its request.
</t>
</list></t>
<t>A user agent SHOULD interpret the abscence of a "Vary" HTTP header with an "accept-profile" value in a response from a server
as the lack of support for profile negotiation for the resource the user agent interacts with.
</t>
<t>A server SHOULD consider representations that do not conform to any of the profiles
listed by a user agent in an "Accept-Profile" header
as non-interpretable by the agent. As such, honoring the user agent preferences in the
profile dimension SHOULD take precedence over honoring content negotiation in other dimensions.</t>
<t>
In <xref target="Req_proconneg_1"/> a user agent requests an RDF serialization from a server and expresses preference for two
media types using the "Accept" header and two profiles using the "Accept-Profile" header.
It uses q-values to express a preference for the profile with profile URI
<http://example.org/shapes/shape-1> over the one with profile URI <http://example.org/shapes/shape-2>.
</t>
<figure title="Client expresses a preference for two profiles" align="left" anchor="Req_proconneg_1">
<artwork align="left"><![CDATA[
GET /document HTTP/1.1
Host: example.org
Accept: text/turtle, application/rdf+xml
Accept-Profile: <http://example.org/shapes/shape-1> ; q=0.8 ,
<http://example.org/shapes/shape-2> ; q=0.5
Connection: close
]]>
</artwork>
</figure>
<t>
<xref target="Res_proconneg_1"/> shows the server's response to the request of <xref target="Req_proconneg_1"/>.
By means of the "Vary" header, the server expresses support for negotiation in both the media type and profile dimensions.
The "profile" link with link target <http://example.org/shapes/shape-2> indicates that the server was able to honor
the user agent's second profile preference. Another "profile" link shows that the delivered representation also conforms
to a profile with profile URI <http://example.org/shapes/shape-3>. Furthermore, using an "alternate" link, the server indicates
support for another profile with <http://example.org/shapes/shape-4> as profile URI. Note that, even if the user agent does not
express profile preferences using the "Accept-Profile" header and the server's "Vary" header would be the same, the "Link" header
would still include a "profile" link to indicate the profile of the representation returned by the server.
</t>
<figure title="Response honors a user agent's preference" align="left" anchor="Res_proconneg_1">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/turtle
Vary: Accept, Accept-Profile
Link: <http://example.org/shapes/shape-2>
; rel="profile" ,
<http://example.org/shapes/shape-3>
; rel="profile" ,
<http://example.org/document>
; rel="alternate"
; type="text/turtle"
; formats="http://example.org/shapes/shape-4"
Content-Length: 8724
Connection: close
...
]]>
</artwork>
</figure>
<t>
<xref target="Res_proconneg_2"/> shows the response to the request of <xref target="Req_proconneg_1"/> in case the server
supports profile negotiation for the resource at hand but can not return a representation that conforms to a profile preferred by the user agent.
The server has chosen to nevertheless return a representation that conforms to profile <http://example.org/shapes/shape-4>,
which is not among the ones preferred by the user agent. The server also reveals the existence of a representation
that conforms to profile <http://example.org/shapes/shape-5>. The server could also choose not to return a default
representation in which case it would return a "406 Not Acceptable" HTTP response code and no response body. It would not
provide any "profile" links but might use "alternate" links with a "formats" attribute to indicate the existence of supported profiles.
</t>
<figure title="Response does not honor a user agent's preference but includes default representation" align="left" anchor="Res_proconneg_2">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/turtle
Vary: Accept, Accept-Profile
Link: <http://example.org/shapes/shape-4>
; rel="profile" ,
<http://example.org/document>
; rel="alternate"
; type="text/turtle"
; formats="http://example.org/shapes/shape-5"
Content-Length: 6333
Connection: close
...
]]>
</artwork>
</figure>
<t>
<xref target="Res_proconneg_3"/> shows the response to the request of <xref target="Req_proconneg_1"/> in case the server
does not support profile negotiation for the resource <http://example.org/document>. It does support negotiation in the media type
dimension and has honoured one of the user agent's preferences with that regard, as can be seen by the "Vary" and "Content-Type" headers.
</t>
<figure title="Response indicates lack of support for proactive profile negotiation" align="left" anchor="Res_proconneg_3">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/turtle
Vary: Accept
Content-Length: 8724
Connection: close
...
]]>
</artwork>
</figure>
</section>
<section title="Reactive Profile Negotiation" anchor="reconneg">
<t>In reactive profile negotiation, the user agent selects the profiled representation that best meets its preferences
on the basis of a list of possible representations it obtains from the server. A server that supports reactive
profile negotiation MUST provide such a list of supported profiled representation as a set of links. These can be provided in the "Link" header or
in a Linkset (<xref target="RFC9264">RFC 9264</xref>). Each of these links:</t>
<t><list style="symbols">
<t>MUST have the "alternate" relation type.</t>
<t>MUST use the "formats" link hint to convey the profile URI of the profile to which the resource that is the link target conforms.</t>
<t>SHOULD use the "allow" link hint to convey the HTTP methods that are supported by the resource that is the link target.</t>
</list></t>
<t><xref target="Req_reconneg_1"/> shows a user agent issuing an HTTP HEAD on a resource in order to determine whether
profiled representations are available for it. <xref target="Res_reconneg_1"/> shows the response of a server that
supports reactive profile negotiation. The response has the "300 Multiple Choices" HTTP status code, and, by means
of "alternate" links in the "Link" header, support for
two profiled representations for the resource at hand is indicated. For each, the URI at which they can be
accessed is provided, as well as the respective profile URIs, media types, and supported HTTP methods. On the basis of this response,
the client can decide whether any of the linked resources conform to a preferred profile, and, if so, access
the respective link target. <xref target="Res_reconneg_2"/> shows the response to an HTTP HEAD issued on the link target
<http://example.org/bibrecord/1/DC> of the first "alternate" link. Note that, in <xref target="Res_reconneg_1"/>,
in case the server would deliver a default representation in response to an HTTP GET request on <http://example.org//bibrecord/1>
it could also respond with a "200 OK" HTTP status code, include a "Content-Length" header, and provide only a single link
pointing to the other available representation.
</t>
<figure title="Client determines support for profiles" align="left" anchor="Req_reconneg_1">
<artwork align="left"><![CDATA[
HEAD /bibrecord/1 HTTP/1.1
Host: example.org
Accept: application/xml
Connection: close
]]>
</artwork>
</figure>
<figure title="Server supports two profiles" align="left" anchor="Res_reconneg_1">
<artwork align="left"><![CDATA[
HTTP/1.1 300 Multiple Choices
Content-Type: text/plain
Link: <http://example.org/bibrecord/1/DC>
; rel="alternate"
; type="application/xml"
; formats="http://purl.org/dc/terms/"
; allow="HEAD,GET,PATCH" ,
<http://example.org/bibrecord/1/BIBFRAME>
; rel="alternate"
; type="application/xml"
; formats="http://id.loc.gov/ontologies/bibframe/"
; allow="HEAD,GET"
Connection: close
]]>
</artwork>
</figure>
<figure title="Response to a client accessesing a profiled representation" align="left" anchor="Res_reconneg_2">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/xml
Link: <http://purl.org/dc/terms/>
; rel="profile" ,
<http://example.org/bibrecord/1/BIBFRAME>
; rel="alternate"
; formats="http://id.loc.gov/ontologies/bibframe/"
; allow="HEAD,GET"
Allow: HEAD, GET, PATCH
Accept-Patch: application/xml-patch+xml
Content-Length: 458
Connection: close
]]>
</artwork>
</figure>
</section>
</section>
<section title="Accept-Profile HTTP Header Syntax" anchor="accept-profile">
<t><xref target="abnf_accept_profile"/> describes the syntax
of the "Accept-Profile" HTTP header,
using the grammar defined in <xref target="RFC5234">RFC 5234</xref> and the rules
defined in <xref target="RFC9110">Section 5.5 of RFC 9110</xref>.
The definitions of "URI-reference" and "weight" are imported from
<xref target="RFC9110">RFC 9110</xref>.</t>
<figure title="ABNF for the "Accept-Profile" HTTP header" anchor="abnf_accept_profile" align="left">
<artwork align="left" type="abnf"><![CDATA[
Accept-Profile = "Accept-Profile" ":"
OWS (accept-value) *(OWS "," OWS accept-value) OWS
accept-value = "<" URI-reference ">" [weight] | accept-value-ext
]]>
</artwork>
</figure>
</section>
</section>
<section title="Writing Profiled Representations" anchor="Writing">
<t>A user agent that wants to submit a profiled representation to a server can use the reactive negotiation approach
to determine the nature of a server's support with this regard.
</t>
<t>A server that allows user agents to submit profiled representations SHOULD follow the directions
for reactive negotiation described in <xref target="reconneg"/>.
</t>
<t>A client that submits a representation that conforms to a profile that was not advertised by the server
by means of the reactive negotiation approach, SHOULD assume that the server is not able to process it.
</t>
<t>A server that fails a submission request due to receiving a payload with a profile that it does not support
MUST respond with a "422 Unprocessable Entity" HTTP status code and
SHOULD use the approach described in <xref target="reconneg"/> to convey profiles that are supported.
</t>
<t>Continuing from <xref target="Res_reconneg_2"/>, <xref target="Req_write_1"/>
shows a user agent issuing an HTTP PATCH against resource <http://example.org/bibrecord/1/DC> in order to update it.
It uses the "Content-Type" header to convey the XML Patch media type of its message body and a link with a "profile" relation type
in the "Link" header to indicate the profile to which it conforms. <xref target="Res_write_1"/> shows the server's response,
indicating that the patch was applied successfully; the server returns the updated representation as message body.
</t>
<figure title="Client submits profiled representation" align="left" anchor="Req_write_1">
<artwork align="left"><![CDATA[
PATCH /bibrecord/1/DC HTTP/1.1
Host: example.org
Content-Type: application/xml-patch+xml
Link: <http://purl.org/dc/terms/>
; rel="profile"
Accept: application/xml
Content-Length: 321
Connection: close
...
]]>
</artwork>
</figure>
<figure title="Server indicates successful submission of profiled representation by client" align="left" anchor="Res_write_1">
<artwork align="left"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Location: http://example.org/bibrecord/1/DC
Link: <http://example.org/bibrecord/1/DC>
; rel=profile" ,
<http://example.org/bibrecord/1/BIBFRAME>
; rel="alternate"
; formats="http://id.loc.gov/ontologies/bibframe/"
; allow="HEAD,GET"
Allow: HEAD, GET, PATCH
Accept-Patch: application/xml-patch+xml
Content-Length: 592
Connection: close
...
]]>
</artwork>
</figure>
<t>If, in <xref target="Req_write_1"/>, the user agent would have issued an HTTP PATCH
on resource <http://example.org/bibrecord/1/DC> indicating that the profile URI of the
patch was <http://id.loc.gov/ontologies/bibframe/>, the response would have a 422 HTTP status code
to express that the profile is not supported by the resource at hand. Such a response is shown in
<xref target="Res_write_2"/>.
As can be seen, the server includes a Link header indicating that the resource <http://example.org/bibrecord/1/DC>
supports the profile <http://purl.org/dc/terms/> and the media type "application/xml",
allowing the client to send a request for a supported representation.
</t>
<figure title="Server indicates unsuccessful submission of profiled representation by client" align="left" anchor="Res_write_2">
<artwork align="left"><![CDATA[
HTTP/1.1 422 Unprocessable Entity
Content-Type: text/plain
Link: <http://example.org/bibrecord/1/DC>
; rel="alternate"
; type="application/xml"
; formats="http://purl.org/dc/terms/"
; allow="HEAD,GET,PATCH"
Content-Length: 110
Connection: close
...
]]>
</artwork>
</figure>
</section>
<section title="IANA Considerations">
<t>
This memo requires IANA to register the Accept-Profile HTTP header defined in
<xref target="accept-profile"></xref> in the appropriate IANA registry:
</t>
<t><list style="symbols">
<t>Header Field Name: Accept-Profile</t>
<t>Applicable Protocol: Hypertext Transfer Protocol (HTTP)</t>
<t>Status: Informational</t>
<t>Author/Change controller: IETF</t>
<t>Specification document(s): this document</t>
</list></t>
<!--
<section title="Content-Profile HTTP Header Registration"></section>
-->
</section>
<section title="Security Considerations"></section>
<section title="Acknowledgments">
<t>Many thanks to our colleagues for feedback: Enno Meijers, Michael L. Nelson</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5234;
&RFC6838;
&RFC7231;
&I-D.nottingham-link-hint;
&RFC6906;
&RFC8288;
&RFC9110;
&RFC9112;
&RFC9264;
</references>
<references title="Informative References">
&RFC4452;
&RFC8141;
&RFC5988;
&SHACL;
&XSD;
<!--
<reference anchor="DSP" target="http://dublincore.org/documents/dc-dsp/">
<front>
<title>Description Set Profiles: A constraint language for Dublin Core Application Profiles</title>
<author initials="M." surname="Nilsson">
<organization>KTH</organization>
</author>
<date year="2008" />
</front>
</reference>
-->
<reference anchor="HeeryAndPatel" target="https://www.ariadne.ac.uk/issue/25/app-profiles/">
<front>
<title>Application Profiles: Mixing and Matching Metadata Schemas</title>
<author initials="R." surname="Heery">
<organization>UK Office for Library and Information networking (UKOLN), University of Bath</organization>
</author>
<author initials="M." surname="Patel">
<organization>UK Office for Library and Information networking (UKOLN), University of Bath</organization>
</author>
<date year="2000"/>
</front>
</reference>
</references>
</back>
</rfc>