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

From: Bob Jolliffe <[email-masked]>
Date: Mon, 7 Aug 2017 15:21:02 +0100

Hello

I have suggested a revised and simplified application below, taking
into account the valuable comments by Sean Leonard and Chris Lilley
regarding charset and RFC 7303.  Hopefully this is now ok.

Type name: application

Subtype name: adx+xml

Required parameters: none

Optional parameters: charset (as for application/xml per RFC 7303)

Encoding considerations:

  As per RFC 7303

Security considerations:

  See the security considerations for application/xml in RFC7303

Interoperability considerations:

  As for application/xml per RFC7303

Published specification:

  See http://ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_ADX_Rev2.0_PC_2017-05-26.pdf

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]

Intended usage:

   COMMON

Restrictions on usage:
  None

Author:  Bob Jolliffe and James Kariuki

   Change controller: QRPH Technical Committee [email-masked]

   Provisional registration? (standards tree only): yes

On 26 April 2017 at 10:51, Bob Jolliffe <[email-masked]> 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 at
> http://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]
>
>
> 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 Committee [email-masked]
>
>    Provisional registration? (standards tree only): yes
>
>
> On 26 April 2017 at 08:06, Martin J. Dürst <[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).  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.
>>>
>>> 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]
>>> 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
>
>

-- 
I am travelling from Sat 24 June to Sunday 2 July.  Access to my email
will be sporadic.  Please be patient and I will respond when I can.