idnits 2.17.1 draft-amundsen-richardson-foster-alps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since a state transition 'descriptor' may define a relation type value, it is important to avoid creating conflicts with existing IANA-registered values. If the resulting link relation type is the same as a registered relation type, the descriptor MUST not change the meaning of the IANA relation type. -- The document date (August 24, 2020) is 1334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TK' is mentioned on line 1150, but not defined ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Amundsen 3 Internet-Draft 4 Intended status: Informational L. Richardson 5 Expires: February 25, 2021 6 M. Foster 7 August 24, 2020 9 Application-Level Profile Semantics (ALPS) 10 draft-amundsen-richardson-foster-alps-03 12 Abstract 14 This document describes ALPS, a data format for defining simple 15 descriptions of application-level semantics, similar in complexity to 16 HTML microformats. An ALPS document can be used as a profile to 17 explain the application semantics of a document with an application- 18 agnostic media type (such as HTML, HAL, Collection+JSON, Siren, 19 etc.). This increases the reusability of profile documents across 20 media types. 22 Editorial Note (To be removed by RFC Editor) 24 Distribution of this document is unlimited. Comments should be sent 25 to the IETF Media-Types mailing list (see 26 ). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 25, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 64 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. Describing Domain-Specific Semantics . . . . . . . . 4 66 1.2.2. ALPS-based Server Implementations . . . . . . . . . . 4 67 1.2.3. ALPS-based Client Implementations . . . . . . . . . . 4 68 1.3. A Simple ALPS Example . . . . . . . . . . . . . . . . . . 5 69 1.4. Identifying an ALPS Document . . . . . . . . . . . . . . 9 70 2. ALPS Documents . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.1. Compliance . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.2. ALPS Document Properties . . . . . . . . . . . . . . . . 10 73 2.2.1. 'alps' . . . . . . . . . . . . . . . . . . . . . . . 10 74 2.2.2. 'doc' . . . . . . . . . . . . . . . . . . . . . . . . 10 75 2.2.3. 'descriptor' . . . . . . . . . . . . . . . . . . . . 11 76 2.2.4. 'ext' . . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.2.5. 'format' . . . . . . . . . . . . . . . . . . . . . . 13 78 2.2.6. 'href' . . . . . . . . . . . . . . . . . . . . . . . 14 79 2.2.7. 'id' . . . . . . . . . . . . . . . . . . . . . . . . 14 80 2.2.8. 'link' . . . . . . . . . . . . . . . . . . . . . . . 16 81 2.2.9. 'name' . . . . . . . . . . . . . . . . . . . . . . . 16 82 2.2.10. 'rel' . . . . . . . . . . . . . . . . . . . . . . . . 17 83 2.2.11. 'rt' . . . . . . . . . . . . . . . . . . . . . . . . 17 84 2.2.12. 'type' . . . . . . . . . . . . . . . . . . . . . . . 17 85 2.2.13. 'value' . . . . . . . . . . . . . . . . . . . . . . . 18 86 2.2.14. 'version' . . . . . . . . . . . . . . . . . . . . . . 18 87 2.3. ALPS Representations . . . . . . . . . . . . . . . . . . 18 88 2.3.1. Sample HTML . . . . . . . . . . . . . . . . . . . . . 18 89 2.3.2. XML Representation Example . . . . . . . . . . . . . 19 90 2.3.3. JSON Representation Example . . . . . . . . . . . . . 20 91 3. Applying ALPS documents to Existing Media Types . . . . . . . 22 92 3.1. Linking to ALPS Documents . . . . . . . . . . . . . . . . 23 94 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 4.1. application/alps+xml . . . . . . . . . . . . . . . . . . 23 96 4.2. application/alps+json . . . . . . . . . . . . . . . . . . 25 97 5. Internationalization Considerations . . . . . . . . . . . . . 26 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 101 7.2. Informative References . . . . . . . . . . . . . . . . . 27 102 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 28 103 A.1. Why are there no URLs in ALPS? . . . . . . . . . . . . . 28 104 A.2. Why is there no workflow component in the ALPS 105 specification? . . . . . . . . . . . . . . . . . . . . . 28 106 A.3. Why is there no way to indicate ranges for semantic 107 descriptors? . . . . . . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 110 1. Introduction 112 This document describes ALPS, a media type for defining simple 113 descriptions of application-level semantics, similar in complexity to 114 HTML microformats. These descriptions contain both human-readable 115 and machine-readable explanations of the semantics. An ALPS document 116 can be used as a profile to explain the application semantics of a 117 document with an application-agnostic media type (such as HTML, HAL, 118 Collection+JSON, Siren. etc.). 120 This document identifies a registry for ALPS documents, (The ALPS 121 Profile Registry or APR). The details of this registry, its goals, 122 and operations are covered in a separate document (TBD). 124 This document also identifies a process for authoring, publishing, 125 and sharing normative human-readable instructions on applying an ALPS 126 document as a profile to responses of a given media type. For 127 example, a document that describes how to apply the semantics of an 128 ALPS profile to an HTML document. 130 This document registers two media-type identifiers with the IANA: 131 'application/alps+xml' ('ALPS+XML') and 'application/alps+json' 132 ('ALPS+JSON'). 134 1.1. Notational Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in[RFC2119]. 140 1.2. Motivation 142 When implementing a hypermedia client/server application using a 143 general media type (HTML, Atom, Collection+JSON, etc.), client and 144 server instances need to share an understanding of domain-specific 145 information such as data element names, link relation values, and 146 state transfer parameters. This information is directly related to 147 the application being implemented (e.g. accounting, contact 148 management, etc.) rather than the media type used in the 149 representations. 151 1.2.1. Describing Domain-Specific Semantics 153 Instead of creating and registering an entirely new media type (i.e. 154 'application/accounting'), representation authors can create an ALPS 155 document that describes a 'profile' of the target domain; one that 156 explains the vital domain-specific semantic descriptors and state 157 transitions. This profile can then be consistently applied to a wide 158 range of media types by server implementors and successfully consumed 159 by client applications. The focus on defining application-level 160 semantics, independent of transfer protocol or media type, makes it 161 possible to serve application-specific representations using an 162 application-agnostic media type. 164 1.2.2. ALPS-based Server Implementations 166 Server implementors can use ALPS documents as a basis for building 167 domain-specific solutions without having to create their own custom 168 media type or re-invent the vocabulary and transition set for a 169 common domain (e.g. accounting, microblogging, etc.). Using a 170 preexisting ALPS profile as a guide, servers can map internal data to 171 commonly-understood semantic descriptors and state transitions, 172 increasing the likelihood that existing client applications (those 173 who share the same understanding of the ALPS document) will be able 174 to successfully interact with that server. 176 1.2.3. ALPS-based Client Implementations 178 Armed with a document's ALPS profile, client applications can 179 associate the ALPS descriptor 'id' and/or 'name' attribute values 180 with the appropriate elements within the document. Client 181 applications can 'code for the profile' and better adjust to detailed 182 changes to the response layout, or even the wholesale replacement of 183 one media type with another. 185 1.3. A Simple ALPS Example 187 Below is an ALPS document that describes elements of a simple 188 request/response interaction in a contact management application. 189 The profile defines a semantic descriptor called 'contact', and three 190 subordinate descriptors ('fullName', 'email', and 'phone'). 192 The ALPS document also defines a single, safe state transition, to be 193 represented by a hypermedia control (e.g. HTML.GET form) with the 194 'id' value of 'collection.' This hypermedia control has one input 195 value ('nameSearch'). When executed, the response will contain one 196 or more 'contact' type items. 198 199 A contact list. 200 202 203 204 205 A simple link/form for getting a list of contacts. 206 207 208 Input for a search form. 209 210 212 213 214 215 A link to an individual contact. 216 217 218 219 220 221 223 ALPS Contact Profile document 225 Implementing the ALPS profile above requires implementing the 226 descriptors defined by the ALPS document. In this case, there are 227 two 'top level' descriptors: the safe state transition ('collection') 228 and the semantic descriptor 'contact'. Below is a single HTML 229 document that shows both these elements in a representation. 231 232 233 235 237 239 240 241
244 245 246 247
249 250 251 257 260 263 265 266 272 275 278 279
252 254 Ann Arbuckle 255 256 258 259 261 123.456.7890 262
267 269 Zelda Zackney 270 271 273 274 276 098.765.4321 277
280 282 284 HTML ALPS Contact Representation 286 HTML representations implement most ALPS elements using HTML's 287 'class' attribute. The 'collection' ID has become the CSS class of 288 an HTML form's submit button. The 'contact' ID has become the CSS 289 class of the TR elements in an HTML table. The subordinate 290 descriptors 'fullname','email', and 'phone' are rendered as the TD 291 elements of each TR. 293 This HAL document uses the same profile to express the same 294 application-level semantics as the HTML document. 296 297 299 301 304 305 307 Ann Arbuckle 308 aa@example.org 309 123.456.7890 310 311 312 314 Zelda Zackney 315 zz@example.org 316 987.664.3210 317 318 320 HAL XML Contacts Representation 322 In a HAL representation, all state transitions ('collection' and 323 'item', in this case) are represented as link relations. All data 324 descriptors ('fullName', 'email', and 'phone') are represented as XML 325 tags named after the descriptors. 327 This Collection+JSON document uses the ALPS profile to express the 328 same application-level semantics as the HTML and HAL documents. 330 { 331 "collection" : { 332 "version" : "1.0", 333 "href" : "http://example.org/contacts/", 335 "links" : [ 336 { 337 "rel" : "profile", 338 "href" : "http://alps.io/profiles/contacts" 339 }, 340 { 341 "rel" : "help", 342 "href" : "http://example.org/help/contacts.html" 343 }, 344 { 345 "rel" : "type", 346 "href" : "http://alps.io/profiles/contacts#contact" 347 } 348 ], 350 "queries" : [ 351 { 352 "rel" : "collection", 353 "rt" : "contact", 354 "href" : "http://example.org/contacts/", 355 "data" : [ 356 { 357 "name" : "nameSearch", 358 "value" : "", 359 "prompt" : "Search Name" 360 } 361 ] 362 } 363 ], 365 "items" : [ 366 { 367 "href" : "http://example.org/contacts/1", 368 "rel" : "item", 369 "rt" : "contact", 370 "data" : [ 371 {"name" : "fullName", "value" : "Ann Arbuckle"}, 372 {"name" : "email", "value" : "aa@example.org"}, 373 {"name" : "phone", "value" : "123.456.7890"} 374 ], 375 "links" : [ 376 { 377 "rel" : "type", 378 "href" : "http://alps.io/profiles/contacts#contact" 379 } 380 ] 381 }, 382 { 383 "href" : "http://example.org/contacts/100", 384 "rel" : "item", 385 "rt" : "contact", 386 "data" : [ 387 { 388 "name" : "fullName", 389 "value" : "Zelda Zackney" 390 }, 391 { 392 "name" : "email", 393 "value" : "zz@example.org" 394 }, 395 { 396 "name" : "phone", 397 "value" : "987.654.3210" 398 } 399 ], 400 "links" : [ 401 { 402 "rel" : "type", 403 "href" : "http://alps.io/profiles/contacts#contact" 404 } 405 ] 406 } 407 ] 408 } 409 } 411 Collection+JSON Contacts Representation 413 The descriptor 'collection' has become the link relation associated 414 with a Collection+JSON query. The descriptors 'fullName', 'email', 415 and 'phone' have become the names of key-value pairs in the items in 416 a Collection+JSON collection. 418 1.4. Identifying an ALPS Document 420 An ALPS vocabulary is identified by a unique URL. This URL SHOULD be 421 dereferencable. All ALPS URLs MUST be unique and all ALPS documents 422 intended for public consumption SHOULD be registered in an ALPS 423 Registry [TK: add text on where/how to find registries -mamund]. 425 In order to reduce load on servers responding to ALPS document 426 requests, it is RECOMMENDED that servers use cache control directives 427 that instruct client apps to locally cache the results. Clients 428 making these ALPS document requests SHOULD honor the server's caching 429 directives. 431 2. ALPS Documents 433 An ALPS document contains a machine-readable collection of 434 identifying strings and their human-readable explanations. An ALPS 435 document can be represented in either XML or JSON format. This 436 section identifies the general elements and properties of an ALPS 437 document, their meaning, and their use, independent of how the 438 document is represented. Section 2.3 provides specific details on 439 constructing a valid ALPS document in XML and in JSON format. 441 2.1. Compliance 443 An implementation is not compliant if it fails to satisfy one or more 444 of the MUST or REQUIRED level requirements. An implementation that 445 satisfies all the MUST or REQUIRED level and all the SHOULD level 446 requirements is said to be 'unconditionally compliant'; one that 447 satisfies all the MUST level requirements but not all the SHOULD 448 level requirements is said to be 'conditionally compliant.' 450 2.2. ALPS Document Properties 452 The ALPS media type defines a small set of properties. These 453 properties appear in both the XML and JSON formats. Below is a list 454 of the properties that can appear in an ALPS document. 456 2.2.1. 'alps' 458 Indicates the root of the ALPS document. This property is REQUIRED, 459 and it SHOULD have one or more 'descriptor' child properties. 461 Examples: 463 XML: ... 465 JSON: { "alps" : ... } 467 2.2.2. 'doc' 469 A text field that contains free-form, usually human-readable, text. 470 The 'doc' element MAY have two properties: 'href' and 'format'. If 471 the 'href' property appears it SHOULD contain a dereferencable URL 472 that points to human-readable text. If the 'format' property appears 473 it SHOULD contain one of the following values: 'text', 'html', 474 'asciidoc', or 'markdown'. Any program processing 'doc' elements 475 SHOULD honor the 'format' directive and parse/render the content 476 appropriately. If the value in the 'format' property is not 477 recognized and/or supported, the processing program MUST treat the 478 content as plain text. If no 'format' property is present, the 479 content SHOULD be treated as plain text. 481 XML:

Date of Birth

...

 483 JSON: { "doc" : { "format" : "text" : "value" : "Date of Birth ..." 484 } } 486 A 'doc' element SHOULD appear as a child of 'descriptor'. When 487 present, it describes the meaning and use of the related 488 'descriptor'. 490 XML: ... 492 JSON: { "descriptor" : { { "doc" : { "value" : "..." } ... } } 494 The 'doc' element MAY appear as a child of 'alps'. When present, it 495 describes the purpose of the ALPS document as a whole. 497 XML: ... ... 499 JSON: { "alps : { "doc" : { "value" : "..." }, ... } } 501 2.2.3. 'descriptor' 503 A 'descriptor' element defines the semantics of specific data 504 elements or state transitions that MAY exist in an associated 505 representation. 507 One or more 'descriptor' elements SHOULD appear as children of 508 'alps'. It may also appear as a child of itself; that is, the 509 'descriptor' property may be nested. 511 The 'descriptor' property SHOULD have either an 'id' or 'href' 512 attribute. It MAY have both. Additionally, the 'descriptor' MAY 513 have any of the following attributes: 515 1. 'doc' 517 2. 'ext' 519 3. 'name' 520 4. 'type' 522 If present, the 'href' property MUST be a dereferenceable URL, that 523 points to another 'descriptor' either within the current ALPS 524 document or in another ALPS document. 526 If 'descriptor' has an 'href' attribute, then 'descriptor' is 527 inheriting all the attributes and sub-properties of the descriptor 528 pointed to by 'href'. When 'descriptor' has a property defined 529 locally, that property value takes precedence over any inherited 530 property value. Since there is no limit to the nesting of elements 531 -- even ones linked remotely -- it is important to process 'all 532 descriptor' chains starting from the bottom to make sure you have 533 collected all the available properties and have established the 534 correct value for each of them. 536 If 'descriptor' is declared at the top level of an ALPS document, 537 then a client SHOULD assume that 'descriptor' can appear anywhere in 538 a runtime message. 540 If 'descriptor' is nested, i.e. declared as a child of another 541 descriptor, then: 543 1. A client SHOULD assume them to appear in any sibling 'descriptor' 544 element and recursively in their child descriptors. 546 2. A client SHOULD NOT assume that it can appear anywhere outside of 547 parent descriptor, unless it was explicitly referenced by another 548 descriptor in 'href' attribute. In that case the same rules are 549 applied to 'descriptor' containing 'href' attribute. 551 2.2.3.1. 'Descriptors and Link Relation Types' 553 When a representation is generated that includes state transitions, 554 valid values for link relation types are: 556 1. A registered IANA link relation type (e.g. rel="edit", a short 557 string). 559 2. An extension link relation type as defined by [RFC5988] whose 560 value is the fully-qualified URI of an associated document 561 describing the relation type. This includes URI fragment 562 identifiers of ALPS descriptors (e.g. 563 rel="http://alps.io/profiles/item#purchased-by", a URI) per the 564 conventions of Section 2.2.7.2. 566 3. The 'id' property of a state transition descriptor of an 567 associated ALPS document (e.g. rel="purchased-by", a short 568 string) per the conventions of section Section 2.2.7.1 and 569 Section 2.2.7.3 if the representation includes an ALPS profile. 571 2.2.4. 'ext' 573 The 'ext' element can be used to extend the ALPS document with 574 author-specific information. It provides a way to customize ALPS 575 documents with additional properties not covered in this 576 specification. This is an OPTIONAL element. 578 The 'ext' element has the following properties. 580 1. 'id' 582 2. 'href' 584 3. 'value' 586 The 'id' property is REQUIRED. The 'href' is RECOMMENDED and it 587 SHOULD point to documentation that explains the use and meaning of 588 this 'ext' element. The 'value' property is OPTIONAL. The content 589 is undetermined; its meaning and use SHOULD be explained by the 590 document found by de-referencing the 'href' property. 592 Examples: 594 XML: 597 JSON: { "ext" : { "id" : "directions", "href" : "http://alps.io/ext/ 598 directions", value="north south east west" } } 600 The 'ext' element MAY appear as a child of the following elements: 602 1. 'alps' 604 2. 'descriptor' 606 Since the 'ext' element has no specific meaning within this 607 specification, it MUST be ignored by any application that does not 608 understand its meaning. 610 2.2.5. 'format' 612 Indicates how the text content should be parsed and/or rendered. 613 This specification identifies a range of possible values for 614 'format': 616 o 'text', for plain text, MUST be supported. 618 o 'html', for HTML, SHOULD be supported. 620 o 'asciidoc', for AsciiDoc, MAY be supported. 622 o 'markdown', per The text/markdown Media Type 623 [I-D.ietf-appsawg-text-markdown], MAY be supported. 625 Any other values for this attribute are undefined and SHOULD be 626 treated as plain text. If the program does not recognize the value 627 of the 'format' property and/or the 'format' property is missing, the 628 content SHOULD be treated as plain text. 630 This property MAY appear as an attribute of the 'doc' element. 632 2.2.6. 'href' 634 Contains a resolvable URL. 636 When it appears as an attribute of a 'descriptor', 'href' points to 637 another 'descriptor' either within the existing ALPS document as a 638 fragment or in another ALPS document as an absolute URL. The URL 639 MUST contain a fragment per Section 2.2.7.2 referencing the related 640 'descriptor'. 642 When it appears as an attribute of 'ext', 'href' points to an 643 external document which provides the definition of the extension. 645 When it appears as an attribute of 'link', 'href' points to an 646 external document whose relationship to the current document or 647 'descriptor' is described by the associated 'rel' property. 649 When it appears as an attribute of 'doc', 'href' points to a document 650 that contains human-readable text that describes the associated 651 'descriptor' or ALPS document. 653 2.2.7. 'id' 655 A document-wide unique identifier for the related element. This 656 SHOULD appear as an attribute of a 'descriptor'. It SHOULD be an 657 opaque string that does not contain any URL unsafe characters per 658 [RFC1738]. 660 The value of this attribute MAY be used as an identifier in the 661 related runtime hypermedia representation. In the example below the 662 ALPS descriptor with an 'id' of 'q' is used to identify an HTML input 663 element: 665 'id' in ALPS... 667 ...becomes the 'class' in HTML 670 It should be noted that the exact mapping from ALPS elements (e.g. 671 'id') to elements within a particular media type (HTML, 672 Collection+JSON, etc.) is covered in separate documents (to be 673 specified). 675 2.2.7.1. ALPS 'id' and 'name' Properties 677 In some cases, media types support non-unique identifiers (e.g. 678 HTML's 'name' property) or will allow the same identifier value for 679 multiple elements in the same representation (e.g.