Skip to main content

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 steering group member) Yes

Yes (2012-10-20 for -06)
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

No Objection (for -07)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -07)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (2012-10-23 for -07)
- 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

No Objection (for -07)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (2012-10-24 for -07)
In support of making this 'Informational'.

(Pete Resnick; former steering group member) No Objection

No Objection (2012-10-25 for -07)
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

No Objection (for -07)

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2012-10-23 for -07)
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

No Objection (for -06)

                            

(Russ Housley; former steering group member) No Objection

No Objection (2012-10-22 for -07)
  I think this document would be better as an Informational RFC.

(Sean Turner; former steering group member) No Objection

No Objection (2012-10-24 for -07)
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

No Objection (2012-10-30 for -07)
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

No Objection (for -07)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (for -07)