Re: [media-types] Review request for application/emergencyCallData.eCall.MSD+per

[Ned Freed <[e-mail]>]

> Just so I’m clear on option 1 when you say “Future types” do you mean
> future types that are “application.EmergencyCallData.*+xml” types, or
> other types that use a period in the same way we’re using it for
> EmergencyCallData?

The problem is that x/y.z is reserved syntax that makes y a facet name. And
EmergencyCallData. is not (currently) a facet name. So we can either treat the
existing application.EmergencyCallData.*+xml as exceptions to this rule or
register EmergencyCallData as a facet name (option 3).

If we opt for the exception to the rule approach we can either leave
the registrations alone (option 1) or create new names for those types and
have the old names as aliases (option 2). If you do this future names
would need to be something like pplication.EmergencyCallData-*+xml.

Does this help?

				Ned

> Brian

> On 9/28/16, 2:49 AM, "Ned Freed" <[e-mail]> wrote:

> >> Hi Ned and Mark,
> >
> >> Thanks for the replies.
> >
> >> Does one of the drafts need to say that it updates Appendix A of RFC
> >> 6838 to permit "EmergencyCallData." as a media subtype prefix,
> >> reserved for data sent during an emergency call?  Or add a statement
> >> without updating RFC 6838?  Or would IESG approval of the drafts be
> >> sufficient?
> >
> >I'm a little unclear about what you're proposing here, so let me just
> >outine
> >your options:
> >
> >(1) You can keep using the existing names
> >application/EmergencyCallData.*+xml
> >    as exceptions per Appendix A of RFC 6838. Future types won't be able
> >to
> >    use this syntax, however.
> >
> >(2) You can rename these types to something that doesn't have facet
> >syntax and
> >    retain the old names as aliases. Future types will need to use the new
> >    syntax.
> >
> >(3) You can write a document that specifies the EmergencyCallData
> >registration
> >    tree per section 3.5 of RFC 6838? A standards action is needed to do
> >this,
> >    and the document will need to cover all the points that RFC 6838
> >covers
> >    for the standards, vendor, personal/vantity, and unregistered trees.
> >
> >				Ned
> >