Subject: [media-types] Is dot (.) basically reserved?

From: Sean Leonard <[email-masked]>
Date: Sat, 18 Jun 2016 15:48:37 -0700

Is it fair to say that the dot (.) is basically a reserved character as a delimiter for facet names in media types, but does that mean it can’t ever be used?

Suppose that I want to register a media type for X.690-encoded values (commonly known as BER, CER, DER) as a whole. (I am not actually going to do this, at least not for the time being. Working on other things...)

application/x.690 makes sense. (application/ber etc. do not make sense, because BER / CER / DER are basically the same. Similarly application/asn.1 does not make sense because this is an encoding of ASN.1, it’s not generic to ASN.1 as a whole.)

However, x. is reserved specifically according to Section 3.4. There is also Section 4.2.

What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically this would call for registering “itu” (or “itu-t”) as a facet, which requires Standards Action. Would subsequent dots then be allowed?

Thanks,

Sean

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 19 Jun 2016 10:45:37 +1000

> On 19 Jun 2016, at 8:48 AM, Sean Leonard <[email-masked]> wrote:
> 

I think this question is the heart of the yang discussion. My reading is that it effectively is in standards tree registrations (since registrations in other trees will already have a dot to denote the facet and therefore registration tree), but this isn't made explicit AFAICT.

> What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically this would call for registering “itu” (or “itu-t”) as a facet, which requires Standards Action. Would subsequent dots then…

I see no reason to disallow them when there's already a facet -- unless that facet reserves them for some reason.

> 
> Thanks,
> 
> Sean
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

--
Mark Nottingham   https://www.mnot.net/

---

From: Ned Freed <[email-masked]>
Date: Sun, 19 Jun 2016 11:35:51 -0700 (PDT)

> Is it fair to say that the dot (.) is basically a reserved character as a
> delimiter for facet names in media types, but does that mean it can’t ever be
> used?

It can't be used in unfaceted names, because using it would make them a faceted
name.

It can, however, be used in facted names, since the second and subsequent
occcurances have no special meaning.

Such are the vagarities of the naming scheme.

> Suppose that I want to register a media type for X.690-encoded values
> (commonly known as BER, CER, DER) as a whole. (I am not actually going to do
> this, at least not for the time being. Working on other things...)

> application/x.690 makes sense. (application/ber etc. do not make sense,
> because BER / CER / DER are basically the same. Similarly application/asn.1
> does not make sense because this is an encoding of ASN.1, it’s not generic to
> ASN.1 as a whole.)

Sure does, but you can't register it. You have to make do with something
like x-690.

> However, x. is reserved specifically according to Section 3.4. There is also

Exactly.

> What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically
> this would call for registering “itu” (or “itu-t”) as a facet, which
> requires Standards Action. Would subsequent dots then be allowed?

Nope, won't work. There's no itu facet.

Now, you can argue that there should be a std. facet, so you can have
std.x.690. That was briefly discussed during the last revision process as I
recall, but there was no consensus to define it.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Jun 2016 15:06:30 -0700 (PDT)

> I think this question is the heart of the yang discussion. My reading is that
> it effectively is in standards tree registrations (since registrations in other
> trees will already have a dot to denote the facet and therefore registration
> tree), but this isn't made explicit AFAICT.

RFC 6838 section 3.1, fourth paragraph:

   Media types in the standards tree MUST NOT have faceted names, unless
   they are grandfathered in using the process described in Appendix A.

> facet reserves them for some reason.

Creating additional facets in order to delegate a portion of the tree to
another standards body (like the ITU) is the main reason why there's a process
to register additional facets; see RFC 6838 section 3.5. But of course there's
an implicit requirement that the ITU be willing and able to set up it's own
administrative process for the new tree. So far nobody has said they want
to do that.

				Ned