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

[Randall Gellens <[e-mail]>]

Hi Ned,

To be clear, if we want to register the three new types as 
application/EmergencyCallData.*+xml we need option (3), which would 
establish the EmergencyCallData tree as an IETF tree?  We would need 
to indicate if it is possible to have vendor, private, and vanity 
facets under this, and indicate the rules for registered 
standards-related uses?  Or am I not understanding the option?

--Randy

At 11:49 PM -0700 9/27/16, Ned Freed 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
>


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Consultants are mystical people who ask a company for a number and then
give it back to them.