Hi,
I don't really feel strongly, but I don't think the document should describe its relation to JSON so closely.
Reading "3.4. YAML and JSON", I think it should be moved to an appendix, if the authors want to keep it. It doesn't contain any requirements.
A really gnarly example might be the differences between ES404 and RFC8259. The "JSON" reference in this document uses RFC8259, but if you want to read a lot of documents from different sources, the browser-influenced ES404 is probably required. None of this is too close to YAML, although I suspect it has similar issues for the same reasons.
Also, one related reason is too brief:
YAML 1.2.2 says:
"On input, a YAML processor must support the UTF-8 and UTF-16 character encodings. For JSON compatibility, the UTF-32 encodings must also be supported."
but RFC8259 says:
"JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629]."
Here, the document defines a Media Type, so that's presumably for interchange. The issue is that both ES404 and RFC8259 describe or allow unpaired surrogates, with ES404 making some other additional processing requirements.
I also think the cyclic references in YAML suggest moving JSON compatibility issues to an appendix. Mozilla had a serialization close to JSON, but that allowed cyclic references. It's not the same problem.
thanks,
Rob
On Mon, Apr 17, 2023 at 1:33 AM Roberto Polli <robipolli@xxxxxxxxx> wrote:
Dear Qin,
thanks for your detailed review!
We discussed them here with the chairs
https://github.com/ietf-wg-httpapi/mediatypes/issues/79
Replies inline. Please let us know if any of these are blocking.
On Sat, 8 Apr 2023 at 16:09, Qin Wu via Datatracker <noreply@xxxxxxxx> wrote:
> I believe this document is well written and ready for publication, however I do
> have a few comments as follows: Major issues: No
Thanks!
> Minor issues:
> 1. Section 2
> For Media Type registration in section 2, I am not clear whether Macintosh file
> type code and Windows Clipboard Name should be mentioned as additional
> information?
The request came from the media type mailing list. They provided a reference
to the SVG media type registration that places this information under
the Additional information.
See https://www.iana.org/assignments/media-types/image/svg+xml
> 2. Section 2.2
> For The +yaml Structured Syntax Suffix in section 2.2, how many contacts do we
> allowed? My impression, in most case, the single contact is preferred, wrong?
The current registration process says that a contact is a "person".
https://www.rfc-editor.org/rfc/rfc6838.html#section-6.2
However, looking at the current registry
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
there appears to be a range of different entries that do not meet the
definition of a person.
To avoid issues we used a wording similar to the +xml SSS
registration, so we think
this should not be an issue. Clearly, if there's an explicit edit
suggestion we are happy
to consider it!
> 3.Section 3.1 said:
> “ While this document is based on a given YAML version [YAML], the
> media type registration does not imply a specific version. This
> allows content negotiation of version-independent YAML resources.
>
> Implementers concerned about features related to a specific YAML
> version can specify it in YAML documents using the %YAML directive
> (see Section 6.8.1 of [YAML]).
> ”
> It looks these two paragraphs contradict to each other, if we see features
> related to a specific YAML version as some kind of YAML resource, should we
> also allow content negotiation of version specific YAML resources? Correct me
> if I am wrong?
Since a YAML resource could theoretically contain different YAML
documents each with its own version,
we used the current wording to warn implementers of possible issues.
We discussed with the YAML community the content negotiation topic,
but we agreed that it was out of scope for the media type registration.
(see the example below: we didn't add it to the document to avoid
fostering this kind of practice).
```
%YAML 1.2
---
a: 1
...
%YAML 1.1
---
b: 1
...
```
We propose the following edit to make things more simple, though:
```
This [YAML] media type registration is independent of YAML version.
```
> 4. Section 3.2 said:
> “
> When receiving a multi-document stream, an application that only
> expects one-document streams, ought to signal an error instead of
> ignoring the extra documents.
>
> Current implementations consider different documents in a stream
> independent, similarly to JSON Text Sequences (see [RFC7464]);
> elements such as anchors are not guaranteed to be referenceable
> across different documents.
>
> ”
> I am a little confused here, Is current implementations documented by this
> draft? Or new implementation related to this draft should consider different
> document in a stream dependently or can detect whether a single document or
> multiple documents are carried in a stream?
Forewords: a "YAML stream" is just the formal name of a YAML resource,
that can contain one or more documents separated by `---`.
The current YAML specifications (and thus, implementations)
consider different documents in a stream as independent.
Since during the editorial work there were some doubts on this behavior,
we clarified this in the Interoperability Considerations.
>> When receiving a multi-document stream, an application that only
>> expects one-document streams, ought to signal an error instead of
>> ignoring the extra documents.
>
> I also suggest we should leave how to signal an error beyond the scope of this
> document.
Reading the above sentence, it doesn't seem to me that it specifies
how to signal an error.
Instead of using normative clauses, here it just says that "ought to
signal an error".
Do you think we need some extra clarification here?
> 5. Section 3.4 figure 3
> Not clear whether figure 3 in section 3.4 should be moved to Appendix A.
> Or some figure in appendix A should be moved to section 3.4, e.g.,
> One interoperability issue， i.e., mapping keys that are not strings
> is clearly related to appendix A.1
We discussed this point in I
https://github.com/ietf-wg-httpapi/mediatypes/issues/79#issuecomment-1506517453
and
we the current place for this figure is appropriate.
This is because non-string mapping keys are a cause of
interoperability issues with JSON as well as pathlike fragment
identifiers.
However, the interoperability issues are not the exact same set for the two.
Let us know if these clarifications are helpful to solve your concerns.
Thanks again for your time and support,
R.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
