IETF Logo Mail Archive

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

Jan Algermissen <jan.algermissen@nordsc.com> Wed, 11 January 2012 09:23 UTC

Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0785A21F8605 for <ietf-types@ietfa.amsl.com>; Wed, 11 Jan 2012 01:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IafQgdi5KziW for <ietf-types@ietfa.amsl.com>; Wed, 11 Jan 2012 01:23:16 -0800 (PST)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38421F85F2 for <ietf-types@ietf.org>; Wed, 11 Jan 2012 01:23:16 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id q0B9MtYh023775 for <ietf-types@iana.org>; Wed, 11 Jan 2012 09:23:15 GMT
Received: from [10.163.29.200] (tmo-110-8.customers.d1-online.com [80.187.110.8]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MAASz-1RrHEo2mpV-00Bsda; Wed, 11 Jan 2012 10:22:52 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <4F0D4A94.407@gmx.de>
Date: Wed, 11 Jan 2012 10:22:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC5008BD-44A0-4838-BE50-540D51088FDF@nordsc.com>
References: <F59F4E2122554F5793C0C7E325D01856@OfficeHP> <61DA936B-79AE-480E-B77A-2415DC18DB08@nordsc.com> <4F0D4A94.407@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:pjb/JqEb17SAPfaigCD0OKfoql3vHXRx43uUUFHgPGQ v46ynK3AA2YURXcLL2zutbnQ8L9GZSAjxr8DB/Tr9u6+u+RVm+ NjHlLNsn6rOmhrmkDOLemvbo/l1AqVJ1NL1SOOWoU1ho19dknC YRYTyPY+tqdiXIuEKSJURN7VDm98ZKmVXj38U9zyCVDdkbJCRl 7S8XLV3E+DykVv+vl9iEc+GGq/dKJXZ0FKosiFw47AOLq5Lds3 2AaHa3USIOj1PBUp6uGzTtckpIg3Q/sCUo+li8jnuAfmlYpOrF uz3dmTrW7SRfhht1M3sEQLiIjqKrXoXJxdnaIDtSoIsKAloc0F r9dfTmsh0sASDfXzshaMdOjM4t2my4Uwkx3BWwvrJy4HEQYIqr dRu+jn7gC+vYw==
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Wed, 11 Jan 2012 09:23:15 +0000 (UTC)
Cc: ietf-types@iana.org, Carl Reed <creed@opengeospatial.org>
Subject: Re: [ietf-types] Request for review application/gml+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2012 09:23:17 -0000

On Jan 11, 2012, at 9:38 AM, Julian Reschke wrote:

> On 2012-01-11 08:05, Jan Algermissen wrote:
>> Carl,
>> 
>> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>> 
>>> "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
>> 
>> 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.
>> ...
> 
> 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



> 
> See
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#rfc.section.6.1.p.13>
> 
> Best regards, Julian
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types

v2.23.0 | Report a Bug | By Email