Additional Media Type Structured Syntax Suffixes
draft-ietf-appsawg-media-type-suffix-regs-08
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Barry Leiba; former steering group member) Yes
This document includes completed registration templates for several registration requests, and the document editors feel strongly that these should be normative references -- they are necessary references for the registrations. I feel equally strongly that they should be informative references. They are normative in the IANA registry, but not, as I see it, in *this document* -- there is no reason whatever that someone needs to understand, say, JSON or the Zip file format in order to read and understand this document. I encourage ADs to weigh in on this in non-blocking comments. I don't think this is an issue to block the document over.
(Adrian Farrel; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
- I agree that this document should be Informational - I agree with Barry's point that the references *in this document* can be informative references.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
In support of making this 'Informational'.
(Pete Resnick; former steering group member) No Objection
Section 3: Author/Change Controller - It seems to me that having the IETF or IESG be the change controller would make more sense than APPSAWG. The WG can always be shut down.
3.x:
The syntax and semantics for fragment
identifiers for a specific "xxx/yyy+json"
SHOULD be processed as follows:
For cases defined in +json, where the
fragment identifier resolves per the +json
rules, then as specified in +json.
For cases defined in +json, where the
fragment identifier does not resolve per
the +json rules, then as specified in "xxx/
yyy+json".
I don't actually understand what the above (and the similar in other sections) means in practice.
3.2/3.3: Shouldn't this document register application/ber and application/der? Wouldn't that make things easier to reference?
3.6: Should there be a reference to RFC 6713 and appropriate registrations for gzip and friends?
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
I encourage changing this to Informational. Nit - since 3.1 is pointing to media-type-reqs for definitions of the registration form headings, should that reference be normative?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
I think this document would be better as an Informational RFC.
(Sean Turner; former steering group member) No Objection
Updated to fix editorial error on my part. I have the question Stephen has about DER/BER. DER is a valid subset of BER and that might be worth pointing out in the BER section ;) Did the WG consider also including CER (defined in X.690), PER (defined in X.691), XER (defined in X.693) for completeness? I know they're not used nearly as widely as DER and BER, but if this is the bucket to include as many as there are defined shouldn't we throw 'em in?
(Stephen Farrell; former steering group member) (was Discuss) No Objection
This was a discuss. Some sets of octets can be corrected decoded as either BER or DER. Could I have xxx/yyy+ber+der in that case or what? I guess there could be a generic question there about octets that can be decoded correctly according to multiple entries from this new suffix registry - is xxx/yyy+zzz+www allowed at all and where's that stated? Alexey says that this is probably ok for the expert to handle, which is fine by me. Might be worth checking the generic question with the list.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection