headers
Carl Reed | 10 Feb 2012 21:44
Favicon

Request for review application/gml+xml - update

There was an initial flurry of dialogue on the the OGC application/gml+xml submission. Clemens Portele provided input in response to your questions. Things have been quiet for a few weeks.
 
I was wondering what happens next?
 
Thanks and regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller 
_______________________________________________
ietf-types mailing list
ietf-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-types
Permalink | Reply | 0 comments |
headers
Mateusz Karcz | 12 Feb 2012 01:35
Picon

Registration of media type text/vnd.matriksoft.mfff.description+xml

Type name:
 text
Subtype name:
 vnd.matriksoft.mfff.description+xml
Required parameters:
 revision <- defined in 
Optional parameters:
 charset <- Same as charset parameter of text/xml as specified in RFC 3023.
Encoding considerations:
 Same as encoding considerations of text/xml as specified in RFC 3023.
Security considerations:
 Same as described in RFC 3023.
 Fragments of file linked with Matriksoft Fragmented File Descriptions are often small in size after
downloading. However, linking output file can be huge. Before linking, the user should check the amount
of available resources.
Interoperability considerations:
 It's XML-based media type. XML is device-, platform-, and vendor-neutral and is supported by a wide range
of Web user agents. Matriksoft Fragmented File Format Description is also platform-neutral.
Published specification:
 http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec
Applications that use this media type:
 Matriksoft DeFragmenter
Additional information:
 Magic number(s): As specified in RFC 3023.
 File extension(s): .mfd .mffd .xml
 Macintosh file type code(s): TEXT
Person & email address to contact for further information:
 Mateusz Karcz
 mateusz.karcz <at> interia.eu
Intended usage:
 COMMON
Restrictions on usage:
 None
Author:
 Mateusz Karcz
Change controller:
 Mateusz Karcz
Permalink | Reply | 2 comments |
headers
Bjoern Hoehrmann | 12 Feb 2012 21:05
Picon

Re: Registration of media type text/vnd.matriksoft.mfff.description+xml

* Mateusz Karcz wrote:
>Type name:
> text
>Subtype name:
> vnd.matriksoft.mfff.description+xml

XML media types under the 'text' top level type are unpopular, it would
probably be a good idea to explain why this does not use 'application'.

>Required parameters:
> revision <- defined in 

Text missing.

>Optional parameters:
> charset <- Same as charset parameter of text/xml as specified in RFC 3023.
>Encoding considerations:
> Same as encoding considerations of text/xml as specified in RFC 3023.
>Security considerations:
> Same as described in RFC 3023.

This suggests there are no other considerations which is unlikely to be
the case. This should probably say something along the lines of "in
addition to ..."

>Additional information:
> Magic number(s): As specified in RFC 3023.
> File extension(s): .mfd .mffd .xml

If there are specific extensions, this should not list "xml" because it
could also be used, there would have to be more specific reasons.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 0 comments |
headers
Paul Libbrecht | 13 Feb 2012 00:23
Favicon

Re: Registration of media type text/vnd.matriksoft.mfff.description+xml

Mateusz,

can you be clearer on the following:

you say:
Intended usage:
COMMON

so one would expect a category of applications to be applicable by this registration.

But you say:

Applications that use this media type:
Matriksoft DeFragmenter

(my intent was to figure out if media of such type would fit into the clipboard, I could not answer this curiosity from this line neither from the web-page).

... or maybe you intended to register an application-specific media-type?
If yes, the vnd tree is for you!

paul
_______________________________________________
ietf-types mailing list
ietf-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-types
Permalink | Reply | 0 comments |
headers
Zach Shelby | 14 Feb 2012 19:47
Favicon
Gravatar

Review of application/link-format registration

draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This draft has a registration for a new
media type in Section 7.3 (also copied below). Your comments would be appreciated.

http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3

Thanks,
Zach Shelby

7.3.  New link-format Internet media type

   This memo registers the a new Internet media type for the CoRE link
   format, application/link-format.

   Type name: application

   Subtype name: link-format

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary data

   Security considerations:

   Multicast requests using CoAP for the well-known link-format
   resources could be used to perform denial of service on a constrained
   network.  A multicast request SHOULD only be accepted if the request
   is sufficiently authenticated and secured using e.g.  IPsec or an
   appropriate object security mechanism.

   CoRE link format parsers should be aware that a link description may
   be cyclical, i.e., contain a link to itself.  These cyclical links
   could be direct or indirect (i.e., through referenced link
   resources).  Care should be taken when parsing link descriptions and
   accessing cyclical links.

   Interoperability considerations:

   Published specification: [[ this document ]]

   Applications that use this media type: CoAP server and client
   implementations for resource discovery and HTTP applications that use
   the link-format as a payload.

   Additional information:

   Magic number(s):

   File extension(s): *.wlnk

   Macintosh file type code(s):

   Intended usage: COMMON

   Restrictions on usage: None

   Author: CoRE WG

   Change controller: IETF
Permalink | Reply | 2 comments |
headers
Peter Saint-Andre | 14 Feb 2012 21:23
Favicon

Re: Review of application/link-format registration

<hat type='AD'/>

Note: I'll request an IETF Last Call on draft-ietf-core-link-format-11
now, which will run concurrently with the expert reviews. I am doing so
in order to get all the reviews finished before IETF 83. Just FYI!

Peter

On 2/14/12 11:47 AM, Zach Shelby wrote:
> draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This draft has a registration for a new
media type in Section 7.3 (also copied below). Your comments would be appreciated.
> 
> http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3
> 
> Thanks,
> Zach Shelby
> 
> 7.3.  New link-format Internet media type
> 
>    This memo registers the a new Internet media type for the CoRE link
>    format, application/link-format.
> 
>    Type name: application
> 
>    Subtype name: link-format
> 
>    Required parameters: None
> 
>    Optional parameters: None
> 
>    Encoding considerations: Binary data
> 
>    Security considerations:
> 
>    Multicast requests using CoAP for the well-known link-format
>    resources could be used to perform denial of service on a constrained
>    network.  A multicast request SHOULD only be accepted if the request
>    is sufficiently authenticated and secured using e.g.  IPsec or an
>    appropriate object security mechanism.
> 
>    CoRE link format parsers should be aware that a link description may
>    be cyclical, i.e., contain a link to itself.  These cyclical links
>    could be direct or indirect (i.e., through referenced link
>    resources).  Care should be taken when parsing link descriptions and
>    accessing cyclical links.
> 
>    Interoperability considerations:
> 
>    Published specification: [[ this document ]]
> 
>    Applications that use this media type: CoAP server and client
>    implementations for resource discovery and HTTP applications that use
>    the link-format as a payload.
> 
>    Additional information:
> 
>    Magic number(s):
> 
>    File extension(s): *.wlnk
> 
>    Macintosh file type code(s):
> 
>    Intended usage: COMMON
> 
>    Restrictions on usage: None
> 
>    Author: CoRE WG
> 
>    Change controller: IETF
> 
> 
> _______________________________________________
> ietf-types mailing list
> ietf-types <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types
Permalink | Reply | 1 comment |
headers
Mateusz Karcz | 16 Feb 2012 21:48
Picon

Registration of media type application/vnd.matriksoft.mfff.fragment

Type name:
 application
Subtype name:
 vnd.matriksoft.mfff.fragment
Required parameters:
 revision <- defined in specification
Encoding considerations:
 Same as encoding considerations of application/octet-stream.
Security considerations:
 Same as security considerations of application/octet-stream and some specific for this format.
 Fragments of file linked using Matriksoft Fragmented File Format processor are often small in size after
downloading. However, linking output file can be huge. Before linking, the user should check the amount
of available resources.
Interoperability considerations:
 MFFF is device-, platform-, and vendor-neutral. Every
Matriksoft Fragmented File Format Description is also platform-neutral. Each program in accordance
with format specification can use this media type.
Published specification:
 http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec
Applications that use this media type:
 Each program in accordance with format specification such as Matriksoft DeFragmenter, can use this media type.
Additional information:
 Magic number(s): none
 File extension(s): .mff
 Macintosh file type code(s): BINA
Person & email address to contact for further information:
 Mateusz Karcz
 mateusz.karcz <at> interia.eu
Intended usage:
 COMMON
Restrictions on usage:
 None
Author:
 Mateusz Karcz
Change controller:
 Mateusz Karcz
Permalink | Reply | 0 comments |
headers
Mateusz Karcz | 16 Feb 2012 21:50
Picon

Registration of media type application/vnd.matriksoft.mfff.fragment - errata

Interoperability considerations:
 MFFF is device-, platform-, and vendor-neutral. Each program in accordance with format specification
can use this media type.
Permalink | Reply | 0 comments |
headers
John R Levine | 21 Feb 2012 19:54

Request for registration of application/gzip and application/zlib

The draft is here:

https://datatracker.ietf.org/doc/draft-levine-application-gzip/

The zlib and gzip formats are defined in RFCs 1950 and 1952. This
defines MIME types for them.

2.  The Application/Zlib Media Type

    Type name: application

    Subtype name: zlib

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1950]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first byte is usually 0x78 but can also be 0x08,
       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
       File extension(s): none
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.zlib.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

3.  The Application/Gzip Media Type

    Type name: application

    Subtype name: gzip

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1952]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first two bytes are 0x1f, 0x8b.
       File extension(s): gz
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.gzip.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

4.  Security Considerations

    Zlib and gzip compression can be used to compress arbitrary binary
    data such as hostile executable code.  Also, data that purports to be
    in zlib or gzip format may not be, and fields that are supposed to be
    flags, lengths, or pointers, could contain anything.  Applications
    should treat any data with due scepticism.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
Permalink | Reply | 9 comments |
headers
Bjoern Hoehrmann | 21 Feb 2012 21:29
Picon

Re: Request for registration of application/gzip and application/zlib

* John R Levine wrote:
>The draft is here:
>
>https://datatracker.ietf.org/doc/draft-levine-application-gzip/

Thank you. The draft should mention that legacy applications have used
application/x-gzip in the past, but that's discouraged, people should
use the types you define instead.

(Most of these comments apply to both types).

>The zlib and gzip formats are defined in RFCs 1950 and 1952. This
>defines MIME types for them.
>
>2.  The Application/Zlib Media Type

I would prefer all lower-case for the type name.

>    Type name: application
>
>    Subtype name: zlib
>
>    Required parameters: none
>
>    Optional parameters: none
>
>    Encoding considerations: needs base64 or other encoding that allows
>    arbitrary binary data

The value should be "8bit" (for both types).

>    Security considerations: See section [security] below
>
>    Interoperability considerations: none

This should probably reference RFC1950.

>    Published specification: [RFC1950]
>
>    Applications that use this media type: anywhere data size is an issue

Same here.

>    Additional information:
>
>       Magic number(s): first byte is usually 0x78 but can also be 0x08,
>       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.

This is confusing.

>       File extension(s): none
>       Macintosh file type code(s): none
>
>    Person and email address to contact for further information: see
>    http://www.zlib.net/

The form in RFC 4288 wants you to use "&" in place of "and".

>4.  Security Considerations
>
>    Zlib and gzip compression can be used to compress arbitrary binary
>    data such as hostile executable code.  Also, data that purports to be
>    in zlib or gzip format may not be, and fields that are supposed to be
>    flags, lengths, or pointers, could contain anything.  Applications
>    should treat any data with due scepticism.

I would prefer simply referencing the two format RFCs, the types as such
do not introduce additional security considerations.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 7 comments |

Gmane