Subject: [ietf-types] Request for review application/gml+xml

From: "Carl Reed" <[email-masked]>
Date: Tue, 10 Jan 2012 18:54:09 -0700

The OGC is requesting review of a proposed GML MIME type. Below is the application formatted using the registration form.

Thank you for your time and consideration.

Carl Reed, PhD
CTO
OGC

Type name: Application

Subtype name: Standards Tree gml+xml

Required parameters:  None

Optional parameters:
   "charset" The charset parameter of application/gml+xml is 
   handled in the same fashion as for application/xml, as specified
   in Section 3.2 of [RFC3023]
   
   "version": If provided, this parameter indicates the GML version
   used in the GML document. Only the major and the first minor
   version number are provided, e.g. "3.2". 

   The value may be provided with or without quotes. i.e., 
   application/gml+xml; version=3.1 shall be treated as identical to
   application/gml+xml; version="3.1".

   In cases where elements from multiple GML versions are used, 
   the parameter shall indicate the highest GML version used in the
   document.

   The parameter can be used to provide protocol-specific operations,
   such as version-based content negotiation in HTTP or in the OGC 
   Web Feature Service.

Encoding considerations: As per Section 3.2 of [RFC3023]

Security considerations:
   The OGC Geography Markup Language (GML) is a generic format for
   exchanging geographic information, but application designers must
   not assume that it provides generic protection against security
   threats.  RFC 3023, section 10, discusses security concerns for
   generic XML, which are also applicable to GML.

   Xlink references in GML documents may cause arbitrary URIs to be
   dereferenced. In this case, the security issues of RFC 3986,
   section 7, should be considered.

Interoperability considerations:
   Different versions of GML specify different XML Schema documents used
   for the validation of GML documents. Starting with version 3.2, the
   GML version information is represented in the namespace. As
   applications may only support a subset of all published GML
   versions, the use of the version parameter is recommended.

Published specification :
   GML (Geography Markup Language) is an international standard
   adopted by both the Open Geospatial Consortium (OGC) and
   International Organization for Standardization (ISO). The latest
   version at the time of this writing is 3.2.1 which is published by
   ISO as ISO 19136:2007. The standard can be accessed freely online at
   http://www.opengeospatial.org/standards/gml.

   The OGC GML MIME specification has also been approved by the OGC
   Membership and is published here:
   http://portal.opengeospatial.org/files/?artifact_id=37743

Applications which use this media type:
   GML is a generic device-, platform-, and vendor-neutral XML
   grammar and is supported by a range of applications creating,
   providing access to and processing geographic information. The use
   of GML is in use internationally with hundreds of deployed
   applications able to create and ingest GML payloads, including all
   of the major GIS vendors, many database providers, earth browzer
   applications, and so forth.

Additional information:

1. Magic number(s):    None. Although no byte sequences can be
    counted on to consistently identify GML documents, GML
    documents will have the sequence http://www.opengis.net/gml
    as part of a namespace declaration to identify the GML
    namespace. This will usually be towards the top of the document.
2. File extension(s): .xml or .gml
3. Macintosh file type code: TEXT
4. Object Identifiers: None

    The OGC is an international voluntary consensus standards
    organization focused on defining and maintaining standards that
    enable interoperability for using geospatial content and services
    in any application that requires the use of geospatial content or
    services. The OGC website is www.opengeospatial.org.

Person & email address to contact for further information:

    Name : Clemens Portele
    Address:Interactive Instruments, Bonn, Germany
    Email : [email-masked]

Intended usage: Common

Restrictions on usage:
    None

Author/Change controller:
    The GML standard is a work product of the Open Geospatial
    Consortium (OGC). The OGC and the GML Standards Working
    Group have change control over the GML standard.

    MIME types for use in OGC standards and formats are defined
    by the OGC Members and discussed and approved by the OGC
    Naming Authority (OGC-NA). The function and role of the OGC-NA
    is described in RFC 5165 and in the OGC Policies and Procedures
    here: http://portal.opengeospatial.org/files/?artifact_id=23325

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

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 08:05:28 +0100

Carl,

On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:

>    such as version-based content negotiation in HTTP

I cannot find the reference just now, but if I am not seriously wrong, media type parameters are not taken into account by HTTP conneg. (How could they, given that their meaning is defined by the media type itself except for q and charset et al.

Jan

> or in the OGC

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2012 09:38:44 +0100

On 2012-01-11 08:05, Jan Algermissen wrote:
> ...

Why would that be a problem?

See

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#rfc.section.6.1.p.13>

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 10:22:48 +0100

> Why would that be a problem?

I think that the correct way of implementing conneg is to strip all media type specific parameters before matching (otherwise the code would need to be aware of the media type specific parameters).

The proposed text above suggests that the version parameter would be recognized by such implementations - which it would not. I.e. 

Accept: application/gml+xml; version=3.1

would maybe yield

Content-Type: application/gml+xml; version=1.2

Or is the intention, that after 'initial standard HTTP conneg' there would be a check for the version parameter in the resource implementation to 'tune' the response entity accordingly?

Sorry if I am confusing this somehow.

Jan

> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2012 10:46:08 +0100

> I think that the correct way of implementing conneg is to strip all media type specific parameters before matching (otherwise the code would need to be aware of the media type specific parameters).

But that's not what is specified in HTTP.

> Content-Type: application/gml+xml; version=1.2

I think that would be a bug according to the HTTP spec.

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 17:50:48 +0100

> But that's not what is specified in HTTP.

Can you point me to that part of the spec? I saw the 'format' example in your reference to media type ranges, but I cannot (personally) read that the way you seem to do.

> I think that would be a bug according to the HTTP spec.

Doh, I am shocked - if you are right then I have lived with a very clouded spot of HTTP in my brain for years.

So you are saying, if there are parameters (besides q) that do not *exactly* match conneg should say 'Not Acceptable'?

IOW, this would also not be correct:

Content-Type: application/gml+xml; version=3.5

And also this would be incorrect:

Accept: application/atom+xml;type=entry

Content-Type: application/atom+xml

Or am I misunderstanding you?

Jan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2012 18:01:35 +0100

> So you are saying, if there are parameters (besides q) that do not *exactly* match conneg should say 'Not Acceptable'?

Well, it's all advisory; so there is wiggle room.

> Or am I misunderstanding you?

No, that's my understanding. But of course I may be wrong; I assume this 
is a feature that hasn't been used a lot yet.

Best regards, Julian