idnits 2.17.1 draft-ark-uri-scheme-00.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 118: '... identifier scheme itself. Users MUST...' RFC 2119 keyword, line 121: '... persistent SHOULD make this clear t...' RFC 2119 keyword, line 122: '... publisher MAY state "Please use the...' RFC 2119 keyword, line 131: '..., those ARKs are RECOMMENDED to be opa...' RFC 2119 keyword, line 132: '...esolves to (if any) MAY be non-opaque....' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2020) is 1460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'URIs' is defined on line 761, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Castelan Castro 3 Internet-Draft 17beta 4 Intended status: Informational April 28, 2020 5 Expires: October 30, 2020 7 The ARK URI scheme 8 draft-ark-uri-scheme-00 10 Abstract 12 This specification defines the 14 (ARK) URI scheme that is especially suitable for persistent 15 identifiers. 17 Persistent identifiers for latest version of this document: 18 . 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 30, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. 54 The ARK (Archival Resource Key) identifier scheme is flexible, 55 dereferenceable and especially suitable for persistent identifiers. 56 A founding principle of the design of the ARK scheme is that 57 persistence is a matter of service not conferred by any particular 58 identifier scheme; ARK is designed to ease the task of achieving 59 persistence. This document specifies the technical details of the 60 ARK system as an URI and IRI scheme and does not elaborate at length 61 on the design rationale of the ARK system; for that see [Kunze_ARK]. 63 2. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [req_words]. 69 The terms "identifier", "resource", "representation", "information 70 resource" and "non-information resource" are used as described in 71 [webarch]. For conciseness we use the term "referent" to mean the 72 resource identified by an identifier. Note that identifiers are 73 strings of characters, representations are strings of octets paired 74 with an interpretation and resources are 76 like the book "Alice's Adventures in Wonderland" by Lewis Carroll or 77 Zermelo-Fraenkel set theory. 79 The notation used to describe syntax is that described in [ABNF] 80 extended as follows: A literal preceeded by " 82 " matches any string that is equivalent when corresponding uppercase 83 and lowercase codepoints in the range 85 to 87 are taken as equivalent. The syntax is augmented with set difference 88 indicated by the operator " 90 " whose precedence is between Alternative and Concatenation. All the 91 syntactic terms defined in [ABNF] are referenced here. 93 3. 95 "ARK" stands for Archival Resource Key. The URI scheme defined in 96 this document is named "ARK scheme". Every identifier that uses this 97 scheme is called an "ARK". The ARK scheme is designed to ease the 98 creation and maintenance of persistent and dereferenceable resource 99 identifiers. An ARK may be used either to identify an information 100 resource or a non-information resource. There are 3 forms of ARKs. 102 The following is an example of a Basic ARK: 104 . " 106 " is the URI scheme " 108 " is the NAAN and " 110 " is the Name. The Embedded ARK 112 corresponds to the above Basic ARK; being a web URI, it can 113 potentially be accessed by any web browser without need for specific 114 support for the ARK scheme. 116 A founding principle of the design of ARK is that persistence is a 117 matter of the service provided by the resolver servicing a persistent 118 identifier not conferred by the identifier scheme itself. Users MUST 119 NOT automatically assume that any published ARK is a persistent 120 identifier. Publishers of ARK that are commited to keep an ARK 121 persistent SHOULD make this clear to the reader. For example, a 122 publisher MAY state "Please use the persistent identifer 124 to reference this page". 126 Every piece of information included in an identifier is subject to 127 become invalid or obsolete with time. An 129 identifier is one that includes no manifest information about what 130 resource it identifiers. When a NAA allocates ARKs that are intended 131 as persistent identifiers, those ARKs are RECOMMENDED to be opaque. 132 The URI that an ARK resolves to (if any) MAY be non-opaque. 134 3.1. 136 ARKs are assigned by NAAs (Name Assigning Authority). Each NAA has 137 an unique NAAN (Name Assigning Authority Number), a string of 138 characters that is included within all the ARKs it allocates. The 139 NAAN is included in ARKs to partition the ARK namespace and avoid 140 collisions between ARKs assigned by different NAAs. The NAA assigns 141 the Name of an ARK that identifies an individual resource. An agent 142 that wants to obtain a NAAN in order to assign ARK identifiers MUST 143 register with the ARK Maintenance Agency [ARK_agency]. A NAA MAY 144 transfer control over its NAAN space to a successor organization to 145 take care of the ARKs it assigned. 147 The NAAN 149 is reserved in perpetuity to be used in examples and NAAN 151 is reserved in perpetuity for invalid ARKs. Applications that handle 152 ARKs SHOULD NOT handle 154 in any special way and SHOULD recognize NAAN 156 as being invalid; the same rationale as in [resrv_domains] applies. 158 The ARK Maintenance Agency keeps the authoritative public registry of 159 all NAA registered along with relevant associated data. See 160 [registry]. As of the time of writing of the present document, the 161 official registry is in a simple plain-text-based format described in 162 a comment at the beginning of the registry itself. 164 Once a NAAN is assigned to a real organization that requested it (as 165 opposed to an assignment that was done on a technical mistake or a 166 misunderstanding) this assignment is permanent and MUST be kept in 167 the registry for as long as the ARK system operates, which is to say, 168 into the indefinite future. 170 Every NAA MUST contact the ARK Maintenance Agence when necessary to 171 keep up to date the prefix of its authoritative resolver and in the 172 same way SHOULD keep up to date the other information kept in the 173 registry. A NAA MUST notify the ARK Maintenance Agency if it expects 174 to stop existing or stop operating a resolver for its NAAN 175 indefinitely (i.e.: notification is not required for temporary 176 downtime of its resolver). 178 3.2. 180 An ARK MAY include a qualifier after the Name. The qualifier can 181 have a ComponentPath and a VariantPath. The ComponentPath is 182 delimited by slashes and indicates hierarchical structure. For 183 example, the ARK 185 has VariantPath 187 . Publishing an ARK with a ComponentPath has the implication that the 188 ARKs obtained by truncating the last segment of the ComponentPath and 189 the previous slash is a container for the untruncated ARK. This 190 semantic implication extends recursively until the ARK with no 191 ComponentPath. Thus in the above example the hiearchical structure 192 (from most general resource to least general) is 194 These implied hierarchical semantics do not extend beyond the ARK 195 with no ComponentPath. A string with no Name part like 197 is not an ARK. If a NAA wants to allocate a ARK to refer to itself, 198 it MUST do so by allocating a Name under its NAAN like for any other 199 resource. 201 The VariantPath is delimited by periods and indicates a language 202 version, media type version, or similar variant of the Basic ARK 203 obtained by stripping the VariantPath. The order of components 204 within a VariantPath is meaningless. ARKs that differ only in order 205 of VariantPath components identify the same resource. Example: The 206 following ARKs are variants of 208 : 210 This specification does not define the concrete semantics of the 211 VariantPath; a NAA SHOULD document the semantic of the ARK it assigns 212 and SHOULD make this documentation accessible to users that 213 dereference the ARK (for example, by including an hyperlink that 214 points to the policy of the NAA in assinging ARKs which in turn 215 describes the semantics of the VariantPath). 217 The use of qualifiers is entirely optional. It is RECOMMENDED that a 218 Basic ARK without qualifiers is used to identify a generic resource 219 (independent of media type and perhaps language). A qualifier MAY be 220 used to identify specific variants that could be short-lived as the 221 preferred media type and languages change in the span of decades and 222 centuries. 224 3.3. 226 A Name Mapping Authority is an agent that provides a dereference 227 service for a set of ARKs; this service MAY be an ARK resolver 228 operated by the NMA (see below) or it MAY be any other suitable 229 means. Example: A NMA could operate a library that lends physical 230 copies of the books identified by the ARKs it services. 232 Ideally all NMAs that service a given ARK would provide the same 233 service. This could fail to be the case in practice because of 234 technical limitations or political reasons, for example: 236 3.4. 238 Inflections are variations of a Basic ARK obtained by adding a URI 239 query. The question sign that introduces the URI query is part of 240 the inflection. If there is no URI query, the inflection is 241 considered the empty string. The inflections of an ARK are meant to 242 provide information and services related to its referent. The ARK 243 system reserves the inflection 245 to request metadata about the referent of an ARK and the association 246 of the ARK with its referent, including any relevant persistence 247 statement. 249 Example: If 251 is the ARK of a PDF document then 253 and 255 can be expected by the user to resolve to a web page with 256 metainformation about the PDF document: Title, author, date of 257 creation and last modification, a statement of persistence (if 258 applicable) by the NAA or NMAH and others. The latter ARK can be 259 entered in a web browser by an user seeking an assurance that the ARK 261 will resolve indefinitelly to this PDF document in order to use the 262 ARK to cite the document in print. 264 A NMAH SHOULD implement the 266 inflection with the semantics described in this document. 268 MUST NOT be used for a different purpose. If a NMAH provides 269 additional inflections, it SHOULD publicly document what they are and 270 their meanings and make this information available to the users of 271 its ARKs. 273 and 275 are reserved for a possible standard meaning in a future revision of 276 this specification. In prior drafts the inflection 278 was recommended to provide metadata about the referent of the ARK and 279 the inflection 281 was recommended to provide information about the assignment of the 282 ARK to its referent including a persistence statement (if 283 applicable). It is RECOMMENDED that a ARK resolver gives the 284 inflections 286 and 288 the same semantics as 290 until and if it is redefined in a future version. 292 4. 294 The syntax of the ARK scheme is described in the context of 295 Internationalized Resource Identifiers (IRIs). For ARKs as URIs the 296 only difference that only ASCII characters are allowed. 298 The core of the ARK system are Basic ARKs. Extended ARKs are the set 299 of all strings allowed under the 301 IRI scheme. Every Basic ARK is an Extended ARK. The syntax of the 302 URI and IRI systems allow identifiers with the 304 scheme that do not met the 306 production rule; those character strings are not ARKs of any type; we 307 call them pseudo-ARKs. 309 The production rules 311 , 313 , 315 , 317 and 319 are taken from [IRIs]. 321 It is RECOMMENDED that applications do not generate Extended ARKs 322 longer than 255 Unicode codepoints. Where a Basic ARK or an Extended 323 ARK is expected, applications MUST NOT impose a limit on length of 324 less than 255 codepoints (that is, Basic ARKs and Extended ARKs of 325 255 codepoints or shorter MUST NOT be rejected by any conforming 326 application on the basis of length). Applications MAY support only 327 URIs and therefore reject Extended ARKs that include non-ASCII 328 characters. 330 4.1. 332 Extended ARKs MAY be embedded as a part of another IRI (URIs are a 333 subset of IRIs). The main application is to couple an extended ARK 334 with a HTTP resolver to make the ARK dereferenceable by ordinary web 335 tools without any additional requirement on the part to the user. 336 Embedded ARKs MUST match the 338 production rule below. The production rules 340 , 342 , 344 , 346 and 348 are taken from [IRIs]. 350 An Extended ARK combined with the 352 of an ARK resolver is an Embedded ARK. Other specification MAY 353 extend the set of Embedded ARKs. The set of Embedded ARK (as defined 354 by the aggregate of all specifications of the Internet) is thus open 355 ended. 357 5. 359 As an IRI scheme, the ARK scheme allows for non-ASCII Unicode 360 characters. It is RECOMMENDED that ARKs minted for new resources use 361 only ASCII characters. Note that ARK normalization always percent- 362 encodes non-ASCII characters. Security issues related to Unicode are 363 mentioned in Section 8. 365 ARK normalization always percent-encodes non-ASCII characters, thus 366 leaving a longer identifier. For example, ARK normalization maps the 367 ARK 369 to 371 . 373 5.1. 375 Percent-encoded characters have long been allowed in the ARK system. 376 Internationalized Resource Identifiers (IRIs) allow non-ASCII 377 characters to be used transparently in IRIs via a mapping to percent- 378 encoded characters. Applications widely implement this mapping; in 379 specific, most web browsers. Forbidding non-ASCII characters in ARKs 380 would have been a moot point because browsers would still allow non- 381 ASCII characters in pseudo-ARKs via the transparent IRI-to-URI 382 mapping. Thus, a decision was made to allow non-ASCII characters in 383 this specification and recommend against them. The only way to 384 reliably disallow non-ASCII characters where ARKs are expected would 385 have been to forbid percent-encoded characters outside ASCII so that 386 the IRI-to-URI mapping always yields invalid ARKs. However this 387 would have broken backward compatibility with previous versions of 388 the ARK scheme which allow percent-encoded characters without 389 restriction. 391 5.2. 393 It may be desirable to avoid Latin characters in a a text written in 394 a different script. In principle, resources in a fixed language that 395 uses a script other than the Latin script could be assigned an opaque 396 persistent identifier with characters in their native script. For 397 example, a scientific journal that publishes articles in Russian 398 language could assign persistent identifiers like 400 to its articles. This comes with an inconvenience for users of non- 401 Cyrillic scripts; they will have more difficulty manually entering 402 this ARK. Therefore, it is RECOMMENDED to avoid this practice. 404 Instead it is RECOMMENDED that a NAA that wants to avoid Latin 405 characters in its identifiers mints ARKs from only decimal characters 406 (" 408 "-" 410 "). Decimal characters are present in most keyboard layouts and are 411 familiar to people around the world more so than the Latin script. 412 The Latin characters in the " 414 " substring at the start of ARKs is unavoidable as long as IRIs are 415 used; IRIs do not allow for non-ASCII characters in the scheme. In 416 hypertext, ARKs can be published with the "ARK" part transliterated 417 into the native script, with the rest of the identifier linked to an 418 Embedded ARK. For example, in Russian one can write 419 "АРК: 421 " where 423 is an hyperlink to 425 . 427 6. 429 Normalization is defined for Extended ARKs. Given an Extended ARK, 430 the following algorithm produces an Exended ARK in normal form. The 431 domain of this algorithm is only Extended ARKs as described in this 432 specification. This algorithm is explicitly undefined for strings 433 other than Extended ARKs. 435 Note that the normalization algorithm decodes all percent-encoded 436 instances of " 438 " in the step of URI syntax-based normalization. Those hyphens are 439 subsequently removed. Therefore, Basic ARKs that differ only by 440 insertion or removal of " 442 " are equivalent. 444 ARKs are said to be equivalent if they have the same normal form. 446 ARK equivalency is an equivalence relation. 448 An extended ARK is a Basic ARK if and only if its normal form is a 449 Basic ARK. 451 The set of Extended ARKs that have the same normal form identify 452 exactly the same resource (this is part of the ARK system independent 453 of any NAA-specific policy in assigning ARKs). Agents MUST NOT 454 declare conflicting assignations for equivalent ARKs; doing so is an 455 error. 457 7. 459 A resolver is an application accessible under a dereferenceable URI 460 scheme that provides a suitable representation for ARKs under its 461 scope. Resolvers MAY use any suitable URI scheme. This 462 specification only describes HTTP resolvers. Other specifications 463 MAY describe additional methods to resolve an ARK. A resolution 464 request is the process of using an ARK resolver to dereference an 465 ARK. 467 Every NAA MUST declare at time of registration at least 1 prefix 468 under which it intends to run an authoritative ARK resolver for its 469 NAAN. Every NAA MUST send a request to the ARK Maintenance Agency 470 [ARK_agency] when necessary to keep the set of its authoritative 471 resolvers up to date. The official list of allocated NAANs and their 472 authoritative resolvers is [registry]. 474 Any method of ARK resolution SHOULD be able to distinguish whether 475 the representation obtained is a representation 477 the resource identified by the ARK or a representation 479 to the resource identified by the ARK. This distinction is made 480 because it is necessary for resources referenced in the Semantic Web. 481 See [cool_URIs]. 483 7.1. 485 A HTTP resolver is one that is accessible through the 487 or 489 scheme. The 491 of an HTTP resolver MUST match the 493 production rule. A HTTP resolver MUST serve HTTP requests for URIs 494 beginning with its corresponding 496 . 498 Given the semantics of the HTTP protocol, resolution is only directly 499 applicable to Extended ARKs with no URI fragment. The fragment, if 500 present, has semantics given by the media type of the response 501 obtained (if any) for resolving the corresponding ARK without the 502 fragment. 504 ARKs that contain non-ASCII characters must be percent-encoded 506 resolution because the 508 in the HTTP protocol only allows URIs (not proper IRIs). The 509 constraints on length limitations apply to the URI resulting after 510 this percent-encoding. 512 URI queries are used for inflections; their semantics and 513 requirements are described in Section 3.4. 515 Clients of the HTTP resolver MUST set 517 in the HTTP request to a Basic ARK. Servers MAY respond with an 518 error status code for requests with a 520 that is not a Basic ARK. 522 A HTTP ARK resolver MUST treat equally all resolution requests for 523 Extended ARKs with the same normal form with the exception that it 524 MAY reject some Extended ARKs on the basis that they are too long. 526 The official resolver for the ARK system has 528 equal to 530 and is operated by [ARK_agency]. 532 7.1.1. 534 The following ARKs MUST NOT be rejected on the basis that they are 535 too long: 537 When a HTTP ARK resolver declines to serve a request for resolution 538 on the basis of length it MUST reply with the HTTP status code 414. 540 Note that the length limit is with respect to the length of Extended 541 ARKs, not the Embedded ARKs used to query an ARK resolver. Internal 542 processing may differ provided these constraints is satisfied. 543 Example: A resolution request for 545 must be treated the same as if it was for 547 or 549 . A HTTP ARK resolver MAY return an error code for requests to 550 resolve something that is not an Extended ARK. 552 7.1.2. 554 If the request is for an Embedded ARK with no inflection, the reply 555 of the resolver is to be interpreted according to the semantics of 556 HTTP with the considerations specific to the ARK system described in 557 this section. Note that these considerations do not apply in the 558 case of an inflected ARK because then the request is not for the 559 referent of the ARK, but for associated metadata instead as described 560 in section Section 3.4. 562 When resolution of an ARK results in a chain of redirects (HTTP 563 status code 301, 302, 303, 307 and 308 MUST be recognized as 564 redirects) followed by a success response which is not a redirect 565 (HTTP status code 200, 204, 206, 226 and 304 MUST be recognized as 566 success), if 568 redirection has status code 303, then the resource at the final 569 location is considered 570 to the ARK resolved, otherwise the resource at the final location 572 the referent of the ARK resolved and the representation obtained is a 573 representation 575 this referent. When a chain of redirects is followed by an error 576 (HTTP status codes 400-599 MUST be recognized as error) this 577 specification does not specify any semantics; therefore, it is 578 unspecified whether the error is of the referent of the ARK or of the 579 resolution of the ARK. Additional responses MAY be recognized as 580 redirect and success or handled the same way as HTTP status code 303 581 provided this is consistent with the relevant specifications. 583 This specification does not define any semantics for HTTP request 584 with an URI corresponding to a HTTP ARK resolver that is not an 585 Embedded ARK. ARK resolvers MAY provide other services under request 586 URIs that are not Embedded ARKs. 588 7.1.3. 590 The following algorithm MAY be used to resolve an ARK using a HTTP 591 resolver. Other algorithms -whether custom or described in a 592 specification- MAY be used instead. If a standard defines an 593 additional resolution procedure it SHOULD follow the same intent as 594 the reference resolution algorithm changing only technical details 595 necessary to adapt to the respective protocols it employs. 597 The reference algorithm presented below is designed to distinguish 598 between information resources and non-information resources 599 identified by an ARK by making use of HTTP status codes as described 600 in [cool_URIs]. 602 The description of the 604 follows. 606 Set 608 to the Embedded ARK formed with the prefix of the ARK resolver 609 specified and the Extended ARK to be resolved. Set 611 to the number specified by the user. Set 613 to the symbol 615 or 617 as specified by the user. Set state to the symbol 618 . Then while 620 is 0 or more: 622 If the above loop ends because 624 reached a negative value, return failure. 626 7.1.4. 628 The ARK Maintenance Agency [ARK_agency] operates an ARK HTTP resolver 629 at 631 . This resolver can resolve any ARK that is globally resolvable by 632 redirecting to the local ARK resolver as stated in [registry]. 634 8. 636 General security considerations of communication within computer 637 networks apply. Ideally resolvers SHOULD be reachable via a secure 638 means. For the case of HTTP resolvers this means using HTTP over 639 TLS. The possibility of connecting securely to an HTTP resolver 640 SHOULD be announced by using the 642 URI scheme in the NMAH. If the resolver is also available under 643 plain HTTP directly over TCP then it SHOULD use HTTP Strict Transport 644 Security (see [HSTS]) to direct users to contact the server securely 645 in the future. 647 The ARK system allows for resolution of identifiers. Many of the 648 security implications of DNS apply. As with any resolution system, a 649 malicious agent can operate an ARK resolver and return undesired 650 responses. Using any ARK resolver requires trust that it will return 651 an honest answer or error message and not a malicious answer 652 analogous to DNS hijacking. Using the ARK system in any way requires 653 some trust in the ARK Maintenance Agency. There is little additional 654 trust required in using the official ARK resolver which is operated 655 by the ARK Maintenance Agency. It is RECOMMENDED that users use the 656 official ARK resolver to resolve ARKs for which there is no 657 particular reason to use another resolver. 659 8.1. 661 The ARK scheme allows non-ASCII Unicode characters in the part 662 assigned by NAAs. See [Unicode_security] and Section 8 in [IRIs] for 663 security implications. The NAAN is always limited to ASCII 664 characters. If a NAA allows a non-trusted party to assign ARKs under 665 its NAAN it SHOULD limit the character set allowed to avoid homoglyph 666 attacks and misplaced formatting characters. An application that 667 displays ARKs can avoid most Unicode-related security problems by 668 displaying ARKs in normalized form which only uses ASCII characters. 669 Applications that expect an ARK and allow non-ASCII characters MUST 670 be prepared for inputs with control or formatting characters inserted 671 maliciously and either reject the input or percent-encode the 672 problematic characters. The production rules of IRIs forbid 673 characters in the range 675 - 677 , 679 - 681 which are control characters. 683 8.1.1. 685 The IRI specification states in prose ([IRIs], p. 18): "IRIs MUST NOT 686 contain bidirectional formatting characters (LRM, RLM, LRE, RLE, LRO, 687 RLO, and PDF).". The set of bidirectional formatting characters is 688 open-ended; therefore it is not possible to forbid all future 689 bidirectional formatting characters in a fixed syntax other than by 690 forbidding unallocated codepoints. For example, 692 (left-to-right isolate) and 694 (right-to-left isolate) were added in Unicode 6.3.0 after the IRI 695 standard was written. Applications MUST avoid passing characters 696 with unknown semantics to other applications. E.g: a program with a 697 command-line interface that handles IRIs should avoid sending 698 unescaped bidi formatting characters in IRIs to the terminal becuase 699 they can garble the following text, unrelated to the IRI. Web 700 software MAY place IRIs that can potentially contain formatting 701 characters inside a 703 XHTML element to limit the effect of bidi formatting characters to 704 the IRI. 706 9. 708 permanent 710 Existing ARK resolvers including the central resolver 711 . Existing NAAs registered in [registry]. 713 Mario Xerxes Castelan Castro (Ksenia) regarding this specification; 714 The ARK Maintenance Agency [ARK_agency] regarding the ARK system in 715 general. 717 ARK Maintenance Agency [ARK_agency]. 719 This document. 721 10. References 723 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 724 Specifications", 2008. 726 [ARK_agency] 727 Agency, A. M., "ARK Maintenance Agency web site", 728 . 730 [cool_URIs] 731 W3C, "Cool URIs for the Semantic Web", 2008, 732 . 734 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 735 Transport Security (HSTS)", 2012. 737 [IRIs] Duerst, M. and M. Suignard, "Internationalized Resource 738 Identifiers (IRIs)", 2005. 740 [Kunze_ARK] 741 Kunze, K., "The ARK Identifier Scheme", 2008, 742 . 744 [registry] 745 Agency, A. M., "Name Assigning Authority Number (NAAN) 746 Registry", . 748 [req_words] 749 Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", 1997. 752 [resrv_domains] 753 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 754 2013. 756 [Unicode_security] 757 Davis, M. and M. Suignard, "Unicode Technical Report #36: 758 Unicode Security Considerations, revision 15", 2014, 759 . 761 [URIs] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 762 Resource Identifier (URI): Generic Syntax", 2005. 764 [webarch] W3C, "Architecture of the World Wide Web, Volume One", 765 2004, . 767 Author's Address 769 Mario Xerxes Castelan Castro (Ksenia) 770 17beta 772 Email: ksenia@17beta.top