Draft: draft-ietf-httpapi-rest-api-mediatypes

Commentary: by removing the section , and marking it and as deprecated aliases of . For use cases presenting YAML content as plain text , the media type is more appropriate . 
 Currently the spec supports fragment identifier based on " named anchors " , e.g. references . Today alias nodes syntax is , but in the future alias nodes could support " pathlike " expressions , e.g. . Can " named anchors " fragment identifiers be extended in the future in a backward compatible way to suppot " alias nodes " syntax ? Consider the following examples is a valid character for a named anchor , using as a pathlike separator might be non - trivial . Currently many YAML parser do only support though , so future YAML spec might restrict the syntax of named anchors might contain non - string characters ( e.g. vs ) . We need to know how pathlike elements are serialized , to identify a human - readable encoding ( e.g.   ) example . A non human - readable encoding such as base64url would solve the issue , since we could just decode the string . This could be supported when pathlike are messy , e.g. 
 Feedback from Maybe we could use something like 
 The easiest solution might be to initially restrict valid characters in the fragment identifier to . This would mean that while not all anchors are addressable , most would be . It would also allow relatively easy extension e.g. by making invalid as an fragment identifier , and therefore usable by a schema that extends it . Not sure how to express it , but it might be good to still reserve for future use by later YAML versions ? 
 Or you could do the inverse and just keep = for application - specific fragment identifier schemes . BTW , why do n't you include  pointer ( RFC6901 ) in the standard set ? That is quite useful for the majority of YAML applications ( certainly the JSON compatible ones ) . 
 WRT sub - mediatypes like openapi and jsonschema , we are discussing in jsonschema supports two fragment identifiers : JSON Pointers and . Plain names are just strings , e.g. " foo " . We could ask if there is some space to tweak the usage of plain names as fragment identifiers . I think it would be useful , but I think it 's YAML community choice ( aka ) . Probably the easiest way to do it is : use JSONPointers if starts with use alias names if starts with This will allow further space for subtypes , eg . use jsonpath if starts with I am not sure that using unstructured strings as fragment identifiers is an interoperable choice at all . What do you think ? 
 What 's the problem that we 're trying to solve here ? If we 're talking about fragment identifiers for , I do n't see why we need to consider other specs at all . If we 're talking about fragment identifiers for , we currently have this : Hence I think the proposal to limit fragment identifiers to makes sense , as that 'll allow targeting nearly all real - world YAML anchors while keeping future YAML - spec compatibility good . Which may later bring in " native " support for something like JSON Pointers , and which this mediatype spec should not try to pre - empt . For cases , many formats need to be embeddable in JSON as well and include some form of internal anchor syntax . Those may of may not want to make the YAML anchors addressable by fragment identifiers as well , but they get to make that choice independently , much like they do already for . 
 Q1 . What 's the problem that we 're trying to solve here ? Identify a fragment identifier syntax that is compatible with existing formats like jsonpath and  pointers Q2 . Why ? Because implementers are accustomed to use json pointers and could for example just ignore our syntax Q3 . Should n't implementers use JSON Pointers only when using openapi+yaml ? Theoretically yes . In practice , since openapi+yaml is not yet registered , implementers just use application / yaml + JSON Pointers . Using will at the same time : enable support for alias nodes ( provided that a suitable encoding is defined in future YAML version ) enable implementation to distinguish between  pointers and alias nodes just using the first character . Q4 . What happens if we do n't find a workaround for JSON Pointers ? There 's the possibility that implementers will anyway continue to use JSON Pointers for processing fragment identifiers . Q4 . Is there some interest in using JSON Pointers in conjunction with ? While I thought there was n't , iiuc wrote that there could be some interest for that ( but please correct me if I 'm wrong ) . 
 We could ask if there is some space to tweak the usage of plain names as fragment identifiers . There 's no reason we could n't constrain how plain name fragments work in future dialects of   , but we still would n't be able to change the media type definition because then it would n't support the existing dialects that do n't have those constraints . 
 Since with plain names do not overlap with application / yaml fragment syntax , implementers could decide to process fragments where ( 0 , " " ) = ~ /^[a - zA - Z]/ as plain names and still be interoperable with YAML . This behavior wo n't be interoperable with other + yaml media types that redefine fragment syntax though . Question : should we specify that supporting further syntaxes in conjunction with application / yaml could create interoperability issues with future implementations ? cc : 
 Closed in 
 For context , I 'm one of the members of the YAML core team and the author of the . We were approached by primarily to ensure that the parent specification includes a proper discussion of the security considerations inherent in workign with YAML . While I strongly support defining the media type , I do not think that the should be defined at this time . The rationale given for this appears to be based on a current difference in browser behaviour , and a nominal need to communicate consumer intent from the source . Defining more than one media type is superfluous , and creates unnecessary uncertainty . The bare - text presentation of YAML content to a human is already now achievable by presenting YAML as , exactly as is the case with  , which canonically uses the media type . If a different medium than GitHub issues is the best way to discuss this , I would be happy to make myself available to any such endeavour . 
 thanks for your feedback ! I think this is the right place to discuss that . to confirm that the yaml community is ok with . Please , integrate the other " deprecated " media types ( eg . application / x - yaml , , ... ) on presenting yaml as : maybe google - chrom just uses for that and does not have a specific behavior wrt and I see that has been deprecated . Can you PR that change ? 
 LGTM
This document registers the following media types used in APIs on the
IANA Media Types registry: text/yaml, application/yaml, application/
openapi+json, and application/openapi+yaml.
This document registers the following media types used in APIs on the
IANA Media Types registry: application/yaml, application/
openapi+json, and application/openapi+yaml.
To increase interoperability when processing API specifications and
leverage content negotiation mechanisms when exchanging OpenAPI
Specification resources this specification register the following
media-types: "text/yaml", "application/yaml", "application/
openapi+json" and "application/openapi+yaml".
To increase interoperability when processing API specifications and
leverage content negotiation mechanisms when exchanging OpenAPI
Specification resources this specification register the following
media-types: "application/yaml", "application/openapi+json" and
"application/openapi+yaml".
Person and email address to contact for further information: See
Authors' Addresses section.
Restrictions on usage: None.
Author: See Authors' Addresses section.