Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt

From: [email-masked]
Date: Tue, 11 Sep 2012 11:59:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Additional Media Type Structured Syntax Suffixes
	Author(s)       : Tony Hansen
                          Alexey Melnikov
	Filename        : draft-ietf-appsawg-media-type-suffix-regs-03.txt
	Pages           : 14
	Date            : 2012-09-11

Abstract:
   A content media type name sometimes includes partitioned meta-
   information distinguish by a Structured Syntax, to permit noting an
   attribute of the media as a suffix to the name.  This document
   defines several Structured Syntax Suffixes for use with media type
   registrations.  In particular, it defines and registers the "+json",
   "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax
   Suffixes, and updates the "+xml" Message Type Structured Syntax
   Suffix registration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-media-type-suffix-regs-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Sep 2012 20:06:00 +0100

>     Suffixes, and updates the "+xml" Message Type Structured Syntax

This version addresses the following issues:

1) make the text about fragment identifiers for +ber/+der consistent 
with the rest of registrations (some minor textual differences, as there 
is no generic application/ber media type registered)

2) added a warning that updates to generic fragment identifier handling 
rules can break existing specific media type registrations.

I didn't feel there was enough support for reversing the fragment 
identifier rules to make media type specific rules override generic 
+suffix rules, so I didn't do this change.

I believe this addresses all outstanding issues I know of.

Please have a quick look and let submit this document to IESG.

Best Regards,
Alexey

---

From: "Rushforth, Peter" <[email-masked]>
Date: Wed, 12 Sep 2012 11:45:12 +0000

Hi,

Is it forbidden by structured suffix reg procedures to register stacked suffixes?
e.g. application/foo+bar+xml

Thanks 
Peter Rushforth

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: September 11, 2012 15:06
> To: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: 
> draft-ietf-appsawg-media-type-suffix-regs-03.txt
> 
> > 	Filename        : 
> draft-ietf-appsawg-media-type-suffix-regs-03.txt
> > 	Pages           : 14
> > 	Date            : 2012-09-11
> >
> > Abstract:
> 1) make the text about fragment identifiers for +ber/+der 
> consistent with the rest of registrations (some minor textual 
> differences, as there is no generic application/ber media 
> type registered)
> 
> 2) added a warning that updates to generic fragment 
> identifier handling rules can break existing specific media 
> type registrations.
> 
> I didn't feel there was enough support for reversing the 
> fragment identifier rules to make media type specific rules 
> override generic 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Rushforth, Peter" <[email-masked]>
Date: Wed, 12 Sep 2012 14:56:13 +0000

Hi again,

RFC 3023 has some discussion of this topic here:

https://tools.ietf.org/html/rfc3023#appendix-A.14

Wondering if that is a preferred approach?

Am I off topic?  If so, apologies.

Thanks
Peter

> [mailto:[email-masked]] On Behalf Of Rushforth, Peter
> Sent: September 12, 2012 07:45
> consistent 
> > with the rest of registrations (some minor textual differences, as 
> > there is no generic application/ber media type registered)
> > 
> > 2) added a warning that updates to generic fragment identifier 
> > handling rules can break existing specific media type registrations.
> >

---

From: Ned Freed <[email-masked]>
Date: Wed, 12 Sep 2012 09:31:29 -0700 (PDT)

> e.g. application/foo+bar+xml

The syntax allows it, but the meaning is undefined. The rule is that the
material after the last plus sign is the suffix. Plus signs before that
currently have no special meaning. Since that could change in the future,
this is one of those things where it makes sense to push back on such
usage in registrations should someone ever try it.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Sep 2012 09:50:45 -0700

> usage in registrations should someone ever try it.

Would you say this constitutes advice for the Designated Expert that
should be added to the draft?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Wed, 12 Sep 2012 14:02:16 -0700 (PDT)

> should be added to the draft?

No. The rule for what pluses mean (and don't mean) is already there. The fact
that things change over time is, among other things, implicit in the process
itself. It is just common sense that multiple plus signs in a name are risky.

Moreover, if you start down that path, there are dozens if not hundreds of
similar common sense considerations for media types that deserve equal if not
greater consideration in these documents Should we have a warning about overly
long (or short) type names? How about a name containing a pointless & intended
primarily for use in an XML context? How about something like $A$B$C$D? (And
yes, several of these sorts of things have been proposed, and saying "that may
not be the greatest idea" has kept all of them out of the registry.)

And that's just names. How about the assessment of whether or not something
qualifies as a type at all, or as a suffix? I bet we could write a dozen pages
on that topic alone, but even assuming we could get consensus, the chances
of that text actually being helpful are low.

Finally, I'll again point out that this is a registry seeding document. Name
selection advice has no business being here.

				Ned