Re: [media-types] media type registration of the Slovak national standard for e-forms container e-form+xml, e-form+zip

[[e-mail]]

Hello,

thank you for your reply.


1. We need to know an IANA-acceptable subtype name for our e-forms  
container in a very short time. It must be written in the Slovak  
legislation and the deadline for the legislation process is in 1 or 2  
weeks from now.

We need to know, what can be the "IANA-approved designation of the  
producer's name".
After a consultation in one of our working groups we propose the  
acronym "gov.sk" for Slovak national standards for information systems  
of public administration defined by the Ministry of finance of the  
Slovak republic (in a standardization process in the Committee for  
standardization of information systems of public administration and  
its working groups).

Is the acronym "gov.sk" acceptable for IANA?
(As an example, it will be used in the following form:  
application/vnd.gov.sk.some-media-type,  
application/vnd.gov.sk.e-form+xml, etc.)

"gov.sk" is the second-level domain name used by the Slovak government  
organizations, such as www.government.gov.sk, www.finance.gov.sk,  
www.nases.gov.sk, etc.

(The contact person for the Ministry of finance of the Slovak republic  
will be Peter Biro - standard ( at ) mfsr.sk )


2. Is the following media type designation acceptable for IANA? :
"e-form+xml" - application/vnd.gov.sk.e-form+xml
"e-form+zip" - application/vnd.gov.sk.e-form+zip


>> 2. I would like to ask you, what registration tree would you suggest for
>> our national e-forms container. "Vendor tree" or "Personal or Vanity tree"?
>
> If it's (or it's going to be) a national standard, then why not  
> Standards Tree? For more details, please see  
> http://tools.ietf.org/html/rfc6838#section-3.1.


Do you think IESG can accept the Ministry of finance of the Slovak  
republic as a recognized standards-related organization? If you think  
so, how long can such a decision take and what is needed for such an  
approval?

Or you think we should submit our specification to the IESG  
standardization process - i.e. for publication as an RFC?

We do not have any experience with the IETF/IESG standardization  
process and I have doubt if it is realistic to try to register our  
national standard in the Standards Tree. Our specifications are  
currently only in the Slovak language and I don't know if or when we  
will create an adequate English version. Our working groups do not  
have enough time and human resources (most of the work is done  
voluntarily). I'm afraid our standardization effort in the Standards  
Tree can get stuck because of these reasons. We need the media type  
registration in a short time.


Thank you for any help.

Stefan Szilva
Viglasska 7
Bratislava
Slovak republic



Citát "Martin J. Dürst" <[e-mail]>:

> Hello Stefan,
>
> On 2014/03/09 00:08, [e-mail] wrote:
>> Dear sirs,
>>
>> I am an idependent member of working groups of the Committee for
>> standardization of information systems of public administration in
>> Slovak republic, which defined a national e-forms container and is
>> working also on another standards. The Committee works under the
>> Ministry of finance of the Slovak republic and its public website is
>> here: http://informatizacia.sk/standards-for-is-pa/4632s
>>
>> The e-forms container will contain all definitions, schemas and
>> transformations needed for a visual and other presentations of an
>> e-government e-form, for filling an e-form, validation of filled data, etc.
>>
>> We would like to register a mimetype for this national e-forms
>> container, but firstly we would like to consult the correct naming.
>>
>>
>> My questions:
>>
>> 1. Is there any experience with registration of media types for national
>> IT or e-government standards? Are there any examples of national
>> standards' subtypes?
>
> I don't remember any such case.
>
>> 2. I would like to ask you, what registration tree would you suggest for
>> our national e-forms container. "Vendor tree" or "Personal or Vanity tree"?
>
> If it's (or it's going to be) a national standard, then why not  
> Standards Tree? For more details, please see  
> http://tools.ietf.org/html/rfc6838#section-3.1.
>
> Regards,   Martin.
>
>> 3. What should be the "IANA-approved designation of the producer's name"
>> in the case of national e-government standard? Are there any written
>> rules for the names?
>>
>>
>> More explanation:
>>
>> The e-forms container will be primarily used by Slovak national
>> e-government portal for publication of all e-forms specifications, but
>> it will be also used by vendors/software producers, who will create and
>> distribute commercial or freeware software for general public and
>> business customers (e.g. economical or accounting software for business,
>> software for filling e-forms, software for e-signing of e-forms, etc).
>> It could be possibly used by other countries or vendors.
>>
>> The container has two equal forms: XML structure or ZIP container.
>> The technical specification of the e-forms container is published as a
>> legislative document - "Edict About Standards for Information Systems of
>> Public Administration" and use of this specification is imposed by the
>> Slovak national legislation. (It is currently available only in Slovak
>> language and the requirements for the e-forms container are defined in
>> this supplement:
>> https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663
>> )
>>
>> The e-forms container is based on existing standards: JAR file format,
>> DublinCore, Open Packaging Format, OpenDocument format, EPUB Open
>> Container Format. The e-forms container also extends these standards for
>> specific e-forms usage.
>>
>>
>> Currently the following nonstandard media types for e-forms containers
>> are used in Slovakia:
>> application/e-form+zip
>> application/x-eform-xml
>>
>> Firstly we thought, we can register something like this:
>> application/vnd.e-form+zip
>> application/vnd.e-form+xml
>> (maybe "e-form" will be only "eform")
>>
>> But if we understand the RFC 6838 correctly, we should create an
>> abbreviation for the organization which is responsible for the Slovak
>> e-government IT standards and this abbreviation must be incorporated in
>> the subtype name.
>>
>> Maybe something like this ? :
>> (note, these are only examples that were not approved or consulted by
>> our Committee)
>>
>> application/vnd.gov.sk.e-form+zip
>> application/vnd.gov.sk.e-form+xml
>>
>> or something like this :
>>
>> application/vnd.finance.gov.sk.e-form+zip
>> application/vnd.finance.gov.sk.e-form+xml
>>
>> Explanation for the "gov.sk": It is the second-level domain name used by
>> the Slovak government organizations, such as www.government.gov.sk,
>> www.finance.gov.sk, www.nases.gov.sk, etc.
>>
>>
>>
>> As an example I filled the registration template for the XML variant of
>> the container, but this is not an official registration request:
>>
>>
>>
>>    Type name: application
>>
>>    Subtype name: Vendor Tree - vnd.gov.sk.e-form+xml
>>
>>    Required parameters:   None.
>>
>>    Optional parameters:  "charset"
>>
>>          UTF-8 is required for Slovak national e-forms containers. This
>> parameter has identical semantics to the charset parameter of the
>> "application/xml" media type as specified in RFC3023.
>>
>>    Encoding considerations:  Identical to those of "application/xml" as
>> described in RFC3023, Section 3.2.
>>
>>    Security considerations:  Files may contain script and other active
>> content.
>>
>>    Interoperability considerations:
>>
>>    Published specification:  (only in Slovak language)
>> https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663
>>
>>
>>    Applications that use this media type:  Slovak e-government portals
>> and (in the future) software from some other vendors.
>>
>>    Fragment identifier considerations:
>>
>>    Additional information:
>>
>>      Deprecated alias names for this type:
>>
>>      Magic number(s):  As specified for "application/xml" in RFC3023,
>> Section 3.2.
>>
>>      File extension(s):  .xml, .eform
>>
>>      Macintosh file type code(s):  TEXT
>>
>>    Person & email address to contact for further information:  National
>> agency for network and electronic services  -  or  -  Ministry of
>> Finance of the Slovak republic
>>
>>    Intended usage: COMMON
>>
>>    (One of COMMON, LIMITED USE, or OBSOLETE.)
>>
>>    Restrictions on usage:
>>
>>    (Any restrictions on where the media type can be used go here.)
>>
>>    Author:
>>
>>
>> ----
>>
>>
>> An incomplete e-forms container structure:
>> - mimetype - e-form mimetype
>> - META-INF/manifest.xml - references and paths of all of the content in
>> the container
>> - meta.xml - e-form identification, version, name, short description and
>> other metadata
>> - schema.xsd - XML Schema for the data.xml
>> - data.xml - optional - user data filled in the e-form
>> - Content/ - presentation schema and transformation schema of the data
>> (primarily XSLT file)
>> - Presentation/ - optional - a presentation containing the data filled
>> by an user (a result of the XSLT transformation of data.xml)
>> - Thumbnails/ - e-form thumbnail
>> - attachments.xml - optional - list of attachments
>> - Attachments/ - optional - attachments listed in attachments.xml
>> - settings.xml - optional - application settings
>>
>>
>> ---
>>
>>
>> Thank you for any help
>>
>> Stefan Szilva
>> Viglasska 7
>> Bratislava
>> Slovak republic
>> [e-mail]
>>
>>
>>
>> _______________________________________________
>> media-types mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/media-types
>>
>