Subject: Re: [media-types] Notice of intent to register a media type

From: Sean Leonard <[email-masked]>
Date: Sat, 20 May 2017 21:09:41 -0700

Hello:

Thanks.

application/* subtypes do not need (and in fact, should not have) a 
charset in most cases. That is for text/* subtypes. The reason is 
because the information is redundant and can lead to mismatch problems. 
(The character encoding is encoded in the encoding attribute of the 
<?xml?> prolog. It is also encoded/deducible with sentinel characters 
such as U+FEFF in UTF-16.)

However, charset is indeed present in RFC 7303. But it is optional. Best 
to leave this alone. (I.e., don't state, or simply say optional, and 
defer to RFC 7303.) Generally you want to refer to RFC 7303 anyway.

An example of a recent application/*+xml type that is very basic and was 
deemed acceptable is:

https://www.iana.org/assignments/media-types/application/lgr+xml

Intended usage:
I think that "LIMITED USE" means "not used very much", as opposed to, 
"used by a very small community". A community of users that is very 
small but uses it actively would be "COMMON". "LIMITED USE" has one foot 
in the grave; "OBSOLETE" is buried 6 feet under. Just my take on it.

Sean

On 4/26/2017 2:51 AM, Bob Jolliffe wrote:
> Thank you Martin for your quick reply.  Taking baby steps, our first 
> step was going to be submitting a provisional registration, for which 
> RFC6838 suggests we just need to have the media type name and contact 
> email filled on the template.
>
> Nevertheless, I have completed the template below in anticipation of 
> the next step.  If reviewers are satisfied we could then move directly 
> to formal registration.  Or else we proceed with provisional 
> registration until the next edition of ADX profile is published later 
> this year or early 2018.
>
> Regards
> Bob Jolliffe
>
> Type name: application
>
> Subtype name: adx+xml
>
> Required parameters: none
> Optional parameters: charset
>    As per rfc3023 the use of charset is strongly recommended.
>    "utf-8" and "utf-16" are the recommended values for maximum compatibility
>    with xml processors.
>
> Encoding considerations:
>    As per application/xml (sec 3.2) of rfc 3023
>
> Security considerations:
>    As a subset of xml, application/adx+xml has all the same security considerations
>    of xml as outlined in sec 10 of rfc 3023.
>    The envisaged usage is for the transport of aggregate (statistical) public health data
>    rather than individual medical record data which would require more stringent
>    considerations relating to privacy.  The ADX profile mandates the use of transport level
>    security when transported over the web.
>      
> Interoperability considerations:
>    Interpretation of the content of this media type presupposes that applications have exchanged
>    structural metadata (primarily codelists) for the controlled vocabularies used in the data message.
>
> Published specification:
>    The original specificaton is published athttp://wiki.ihe.net/index.php/Aggregate_Data_Exchange.
>    An updated publication profiling adx transport is expected 2017/2018
>
> Applications that use this media type:
>    A wide variety of systems involved in routine public health reporting.
>
> Fragment identifier considerations:
>    None
> Additional information:
>    None
> Deprecated alias names for this type:
>    N/A
> Magic number(s):
>    N/A
> File extension(s):
>    N/A
> Macintosh file type code(s):
>    N/A
> Person & email address to contact for further information:
>    QRPH Technical committee :[email-masked] <mailto:[email-masked]>
> <https://tools.ietf.org/html/rfc6838#page-23>
> Intended usage:
>
>     COMMON, LIMITED USE
>     (not too sure. There is no intention to limit the usage)
>
> Restrictions on usage:
>    None
> Author:  Bob Jolliffe and James Kariuki
>
>     Change controller: QRPH Technical [email-masked] <mailto:[email-masked]>
>
>     Provisional registration? (standards tree only): yes
>
>
> On 26 April 2017 at 08:06, Martin J. Dürst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Bob,
>
>     Please send us your intended registration template directly in the
>     mail (not just a pointer, and preferably not an attachment). That
>     will make it easier for the people on this list to give you feedback.
>
>     Regards,   Martin.
>
>
>     On 2017/04/25 17:15, Bob Jolliffe wrote:
>
>         Good day.
>
>         I am writing on behalf of the Technical Committee of Quality
>         Research and
>         Public Health within IHE (Integrating the Healthcare Enterprise -
>         http://ihe.net).
>
>         Myself and James Kariuki (copied) are working on a profile for
>         aggregate
>         health data exchange within that committee.  The profile (ADX) was
>         originally published for trial implementation in 2015 (
>         http://wiki.ihe.net/index.php/Aggregate_Data_Exchange
>         <http://wiki.ihe.net/index.php/Aggregate_Data_Exchange>). We
>         are currently
>         engaged in maintenance work updating and extending the profile.
>
>         We have defined a particular content type for ADX data
>         messages which we
>         would like to use the mime-type "application/adx+xml".
>
>         Following the recommendations of RFC 6838 we have verified
>         that this mime
>         type is not currently registered.  What we would like to do
>         next, pending
>         feedback on this mail, is to complete a provisional
>         registration.  We would
>         move that to a full registration following publication by the
>         technical
>         committee at the end of this cycle.
>
>         The work of the QRPH TC can be viewed at
>         http://wiki.ihe.net/index.php/Quality,_Research_and_Public_Health
>         <http://wiki.ihe.net/index.php/Quality,_Research_and_Public_Health>.
>
>         The co-chairs of the TC, John Stamm and Derek Ritz, are copied
>         on this
>         mail.
>
>         Please advise if we missing any procedural steps or any other
>         feedback that
>         might be useful.
>
>         Regards
>         Bob Jolliffe
>
>
>
>         _______________________________________________
>         media-types mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/media-types
>         <https://www.ietf.org/mailman/listinfo/media-types>
>
>
>     -- 
>     Prof. Dr.sc. Martin J. Dürst
>     Department of Intelligent Information Technology
>     College of Science and Engineering
>     Aoyama Gakuin University
>     Fuchinobe 5-1-10, Chuo-ku, Sagamihara
>     252-5258 Japan
>
>
>
>
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Chris Lilley <[email-masked]>
Date: Sun, 21 May 2017 20:11:16 -0400

Backing up what Sean said:

On 21/05/2017 00:09, Sean Leonard wrote:
> charset in most cases. 

> However, charset is indeed present in RFC 7303. But it is optional. 
> Best to leave this alone. (I.e., don't state, or simply say optional, 
> and defer to RFC 7303.) Generally you want to refer to RFC 7303 anyway.
Right, This was a major change in RFC 7303 from the predecessor, RFC 
3023, where it wasstrongly recommended. While not going so far as to 
prohibit it for the application/*+xml types, it should only be needed 
very rarely.

In general, all references to RFC 3023 must be replaced with RFC 7303, 
which obsoletes it.

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media