Additional Media Type Structured Syntax Suffixes
draft-ietf-appsawg-media-type-suffix-regs-08
Yes
No Objection
(Adrian Farrel)
(Benoît Claise)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 06 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2012-10-20 for -06)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2012-10-23 for -07)
Unknown
- 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 IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2012-10-24 for -07)
Unknown
In support of making this 'Informational'.
Pete Resnick Former IESG member
No Objection
No Objection
(2012-10-25 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2012-10-23 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-10-22 for -07)
Unknown
I think this document would be better as an Informational RFC.
Sean Turner Former IESG member
No Objection
No Objection
(2012-10-24 for -07)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2012-10-30 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -07)
Unknown