Subject: Re: [ietf-types] [apps-discuss] HTML5 and RFC 2854
From: Pete Resnick <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: Mykyta Yevstifeyev <[email-masked]>, [email-masked], Apps-discuss list <[email-masked]>, [email-masked]
Date: Sun, 26 Jun 2011 22:41:30 -0500
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On 6/25/11 6:20 AM, Julian Reschke wrote:
> On 2011-06-25 13:16, Mykyta Yevstifeyev wrote:
>> Currently copying this to [email-masked] . I personally think HTML5
>> should be backwards-compatible with previous version as well as the
>> media type defined for that version. So, first what should be done is
> > ...
>
> But it isn't. It forbids certain things that were allowed before and 
> which are in use.
>
> I believe that in this case, a single level of indirection, like the 
> one we have in RFC 2854, is the right thing.

I agree. HTML defines, internal to the document, the version of HTML it 
is using, often in a DOCTYPE directive. 2854 points to authoritative 
documents for the different versions of HTML and thereby defines the 
MIME type. It seems perfectly reasonable for a new IETF document to 
update (or obsolete) 2854 giving pointers to HTML5 *and all of the prior 
versions of HTML* that might be found in a text/html MIME body.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sat, 25 Jun 2011 13:20:48 +0200
From: Julian Reschke <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
Cc: [email-masked], Apps-discuss list <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] [apps-discuss] HTML5 and RFC 2854

On 2011-06-25 13:16, Mykyta Yevstifeyev wrote:
> Currently copying this to [email-masked] . I personally think HTML5
> should be backwards-compatible with previous version as well as the
> media type defined for that version. So, first what should be done is
 > ...

But it isn't. It forbids certain things that were allowed before and 
which are in use.

I believe that in this case, a single level of indirection, like the one 
we have in RFC 2854, is the right thing.

Best regards, Julian

Date: Sat, 25 Jun 2011 14:16:49 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked], Apps-discuss list <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] [apps-discuss] HTML5 and RFC 2854

25.06.2011 12:52, Julian Reschke wrote:
> On 2011-06-24 19:04, Mykyta Yevstifeyev wrote:
>> Hello all,
>>
>> Cross-posting this to Apps-discuss and html-comments lists. The proposed
>> HTML5 specification (http://dev.w3.org/html5/spec/), which is currently
>> in Last Call, in its Section 12.1 updates the registration of text/html
>> media type. I should note that we have RFC 2854
>> (http://tools.ietf.org/html/rfc2854) which also specifies this media
>> type. Therefore the question is what should be done with this RFC.
>> Should it be retired upon approval of HTML5? Or something else?
>>
>> Mykyta Yevstifeyev
>
> HTML5 currently tries to obsolete RFC 2854; I believe this is a problem.
>
> From <http://tools.ietf.org/html/rfc4288#section-9>:
>
>    Changes should be requested only when there are serious omissions or
>    errors in the published specification.  When review is required, a
>    change request may be denied if it renders entities that were valid
>    under the previous definition invalid under the new definition.
>
> Note the second sentence; many currently valid HTML4 documents aren't 
> valid HTML5 documents anymore. Thus, a document updating the media 
> type registration for text/html will need to continue to allow 
> HTML4.01 documents as well.
Currently copying this to [email-masked] .  I personally think 
HTML5 should be backwards-compatible with previous version as well as 
the media type defined for that version.  So, first what should be done 
is identification whether there are some issue which make create 
confusion with the aforementioned regulations of RFC 4288.  Next, if it 
doesn't, IANA should update registration of this media type with 
reference to HTML5, not RFC 2854.  RFC 2854 itself should then be moved 
to Historic in order to represent it isn't an authoritative definition 
any more.  This won't create confusion with different definitions of the 
media type.

Just my opinion.

Mykyta Yevstifeyev
>
> See related HTML WG issue: <http://www.w3.org/html/wg/tracker/issues/53>
>
> Best regards, Julian
>

Date: Mon, 20 Jun 2011 11:48:25 +0100
From: Stewart Bryant <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct
Reply-To: [email-masked]

Hi Paul

Thank you for the suggestion.

RTG will follow IETF best practice on this and to that end
I will take the advice of my IESG colleges who are have
more experience with ietf-types.

- Stewart

On 18/06/2011 21:37, Paul Libbrecht wrote:
> Stewart,
>
> would you consider adding information in this registration request about names of the clipboard flavors?
> My modest experience has shown me that importing files with certificates is rather a painful approach but drag-and-dropping or copy-and-pasting them worked much better.
>
> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI Manifest") and Macintosh Uniform Type Identifier (e.g. "public.rpki.manifest").
>
> paul
>
>
> Le 17 juin 2011 à 15:14, Stewart Bryant a écrit :
>
>> draft-ietf-sidr-repos-struct
>>
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/
>>
>> Makes the following types request.
>>
>> Review comments by 1 July would be appreciated.
>>
>> Many thanks
>>
>> - Stewart
>>
>>
>>
>> 7.1.1.  application/rpki-manifest
>>
>>    MIME media type name:  application
>>    MIME subtype name:  rpki-manifest
>>    Required parameters:  None
>>    Optional parameters:  None
>>    Encoding considerations:  binary
>>    Security considerations:  Carries a RPKI Manifest
>>       [I-D.ietf-sidr-rpki-manifests].
>>    Interoperability considerations:  None
>>    Published specification:  This document
>>    Applications which use this media type:  Any MIME-complaint transport
>>    Additional information:
>>       Magic number(s):  None
>>       File extension(s):  .mft
>>       Macintosh File Type Code(s):
>>    Person&   email address to contact for further information:  Geoff
>>       Huston<[email-masked]>
>>    Intended usage:  COMMON
>>    Author/Change controller:  Geoff Huston<[email-masked]>
>>
>> 7.1.2.  application/rpki-roa
>>
>>    MIME media type name:  application>
>>    MIME subtype name:  rpki-roa
>>    Required parameters:  None
>>    Optional parameters:  None
>>    Encoding considerations:  binary
>>    Security considerations:  Carries a RPKI ROA
>>       [I-D.ietf-sidr-roa-format]
>>    Interoperability considerations:  None
>>
>> Huston, et al.          Expires December 10, 2011              [Page 12]
>> Internet-Draft        ResCert Repository Structure             June 2011
>>
>>    Published specification:  This document
>>    Applications which use this media type:  Any MIME-complaint transport
>>    Additional information:
>>       Magic number(s):  None
>>       File extension(s):  .roa
>>       Macintosh File Type Code(s):
>>    Person&   email address to contact for further information:  Geoff
>>       Huston<[email-masked]>
>>    Intended usage:  COMMON
>>    Author/Change controller:  Geoff Huston<[email-masked]>
>>
>> _______________________________________________
>> ietf-types mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-types
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Date: Mon, 20 Jun 2011 12:40:58 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: "Eric Prud'hommeaux" <[email-masked]>
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] are http://tools.ietf.org/html/*.html appropriate for scholarly reference?

Hello Eric,

On 2011/06/19 0:54, Eric Prud'hommeaux wrote:
> * "Martin J. DÃ¼rst"<[email-masked]>  [2011-06-18 14:46+0900]

>> If you look at the 'right' copy online, e.g.
>> http://tools.ietf.org/html/rfc2048, then it actually gets updated
>> :-). So one way to help with this is to use the 'right' reference
>> where possible (e.g. in the W3C), and to push this kind of format
>> (or a similar one) from the IETF and the RFC Editor.
>
> If that is indeed the 'right' reference, I'd certainly prefer to reference the HTML, with anchors and all that web-y stuff, over http://www.ietf.org/rfc/rfc*.txt. Iirc, the /html/ dir started sort of unofficially, with a few RFCs offered as an aid to a growingly hypertext web. The decades have past and no doubt social contracts have changed; is there enough of a guarantee of stability that ISO, OASIS, W3C, journals etc. can reference the HTML versions?

In my understanding, the "official" answer to this question would still 
be: The *right* reference is referencing the RFC as such, without any 
link, the same way it would have been done pre-Web.

Of course, that's not very user-friendly these days, so that's why many 
formats add a link. Once you do that, you have to balance 
user-friendliness and stability yourself. Also, the more you use links 
to a particular location, the more you create social pressure to not 
change that. And in the end, if the link ever goes away, people will 
still know how to search for the RFC anyway. The rest is your choice.

Regards,   Martin.

From: Paul Libbrecht <[email-masked]>
Date: Sat, 18 Jun 2011 22:37:56 +0200
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

Stewart,

would you consider adding information in this registration request about =
names of the clipboard flavors?
My modest experience has shown me that importing files with certificates =
is rather a painful approach but drag-and-dropping or copy-and-pasting =
them worked much better.

If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI =
Manifest") and Macintosh Uniform Type Identifier (e.g. =
"public.rpki.manifest").

paul

Le 17 juin 2011 =E0 15:14, Stewart Bryant a =E9crit :

>=20
> draft-ietf-sidr-repos-struct
>=20
> https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/
>=20
> Makes the following types request.
>=20
> Review comments by 1 July would be appreciated.
>=20
> Many thanks
>=20
> - Stewart
>=20
>=20
>=20
> 7.1.1.  application/rpki-manifest
>=20
>   MIME media type name:  application
>   MIME subtype name:  rpki-manifest
>   Required parameters:  None
>   Optional parameters:  None
>   Encoding considerations:  binary
>   Security considerations:  Carries a RPKI Manifest
>      [I-D.ietf-sidr-rpki-manifests].
>   Interoperability considerations:  None
>   Published specification:  This document
>   Applications which use this media type:  Any MIME-complaint =
transport
>   Additional information:
>      Magic number(s):  None
>      File extension(s):  .mft
>      Macintosh File Type Code(s):
>   Person&  email address to contact for further information:  Geoff
>      Huston<[email-masked]>
>   Intended usage:  COMMON
>   Author/Change controller:  Geoff Huston<[email-masked]>
>=20
> 7.1.2.  application/rpki-roa
>=20
>   MIME media type name:  application>
>   MIME subtype name:  rpki-roa
>   Required parameters:  None
>   Optional parameters:  None
>   Encoding considerations:  binary
>   Security considerations:  Carries a RPKI ROA
>      [I-D.ietf-sidr-roa-format]
>   Interoperability considerations:  None
>=20
> Huston, et al.          Expires December 10, 2011              [Page =
12]
> Internet-Draft        ResCert Repository Structure             June =
2011
>=20
>   Published specification:  This document
>   Applications which use this media type:  Any MIME-complaint =
transport
>   Additional information:
>      Magic number(s):  None
>      File extension(s):  .roa
>      Macintosh File Type Code(s):
>   Person&  email address to contact for further information:  Geoff
>      Huston<[email-masked]>
>   Intended usage:  COMMON
>   Author/Change controller:  Geoff Huston<[email-masked]>
>=20
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Sender: "Eric Prud'hommeaux" <[email-masked]>
Date: Sat, 18 Jun 2011 11:54:04 -0400
From: Eric Prud'hommeaux <[email-masked]>
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: World Wide Web Consortium (W3C) - http://www.w3.org/
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: [ietf-types] are http://tools.ietf.org/html/*.html appropriate for scholarly reference?

* "Martin J. DÃ¼rst" <[email-masked]> [2011-06-18 14:46+0900]
> On 2011/06/18 0:00, Chris Lilley wrote:
> 
> >People reading RFC 2048 think they know
> >a) which template to use
> 
> >Also, I assume its a policy decision that RFCs once published are never updated to say that they are obsoleted; but perhapsit is time to review that decision? I imagine most people consult an online copy nowadays rather than taking out a dusty pile of lineprinter paper to read.
> 
> If you look at the 'right' copy online, e.g.
> http://tools.ietf.org/html/rfc2048, then it actually gets updated
> :-). So one way to help with this is to use the 'right' reference
> where possible (e.g. in the W3C), and to push this kind of format
> (or a similar one) from the IETF and the RFC Editor.

If that is indeed the 'right' reference, I'd certainly prefer to reference the HTML, with anchors and all that web-y stuff, over http://www.ietf.org/rfc/rfc*.txt. Iirc, the /html/ dir started sort of unofficially, with a few RFCs offered as an aid to a growingly hypertext web. The decades have past and no doubt social contracts have changed; is there enough of a guarantee of stability that ISO, OASIS, W3C, journals etc. can reference the HTML versions?

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

-- 
-ericP

Date: Sat, 18 Jun 2011 10:10:16 +0200
From: Julian Reschke <[email-masked]>
To: Chris Lilley <[email-masked]>
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] outdated template

On 2011-06-17 17:00, Chris Lilley wrote:
> On Friday, June 17, 2011, 4:52:23 PM, Peter wrote:
>
> PSA>  On 6/17/11 7:22 AM, Bjoern Hoehrmann wrote:
>>> * Stewart Bryant wrote:
>>>> 7.1.1.  application/rpki-manifest
>
>>>>     MIME media type name:  application
>>>>     MIME subtype name:  rpki-manifest
>
>>> This uses an outdated template, the current template is in RFC 4288.
>
> PSA>  Bjoern, I notice that many of your reviews start with "this uses an
> PSA>  outdated template". Do we need to update pointers somewhere so that
> PSA>  people know which template to use?
>
> People reading RFC 4288  know
> a) which template to use
> b) that it obsoletes RFC 2048
>
> People reading RFC 2048 think they know
> a) which template to use
>
> and they know that it obsoletes some older RFCs but don't know (from reading the text) that it is obsoleted by RFC 4288.
>
> I have seen a checker for documents, to make sure the referenced RFCs are up to date; is there a tool (that doesn't start with a document), to see if a single RFC is the latest?
> ...

Nowadays there's a status page at rfc-editor.org, for instance:

   http://www.rfc-editor.org/info/rfc2048

And yes, this link appears in the new RFCs as well; but as you have 
observed this doesn't help with old ones.

And, as Martin pointed out, the HTMLized versions on tools.ietf.org are 
very useful. Use them whenever you can (despite they are not the 
"canonical" versions).

Best regards, Julian

Date: Sat, 18 Jun 2011 14:46:14 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Chris Lilley <[email-masked]>
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] outdated template

On 2011/06/18 0:00, Chris Lilley wrote:

> People reading RFC 2048 think they know
> a) which template to use

> Also, I assume its a policy decision that RFCs once published are never updated to say that they are obsoleted; but perhapsit is time to review that decision? I imagine most people consult an online copy nowadays rather than taking out a dusty pile of lineprinter paper to read.

If you look at the 'right' copy online, e.g. 
http://tools.ietf.org/html/rfc2048, then it actually gets updated :-). 
So one way to help with this is to use the 'right' reference where 
possible (e.g. in the W3C), and to push this kind of format (or a 
similar one) from the IETF and the RFC Editor.

Regards,   Martin.

Date: Fri, 17 Jun 2011 09:07:43 -0600
From: Peter Saint-Andre <[email-masked]>
To: Chris Lilley <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] outdated template

This is a cryptographically signed message in MIME format.

--------------ms030104080205050903090606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/17/11 9:00 AM, Chris Lilley wrote:
> On Friday, June 17, 2011, 4:52:23 PM, Peter wrote:
>=20
> PSA> On 6/17/11 7:22 AM, Bjoern Hoehrmann wrote:
>>> * Stewart Bryant wrote:
>>>> 7.1.1.  application/rpki-manifest
>=20
>>>> MIME media type name:  application MIME subtype name:
>>>> rpki-manifest
>=20
>>> This uses an outdated template, the current template is in RFC
>>> 4288.
>=20
> PSA> Bjoern, I notice that many of your reviews start with "this uses
> an PSA> outdated template". Do we need to update pointers somewhere
> so that PSA> people know which template to use?
>=20
> People reading RFC 4288  know a) which template to use b) that it
> obsoletes RFC 2048
>=20
> People reading RFC 2048 think they know a) which template to use
>=20
> and they know that it obsoletes some older RFCs but don't know (from
> reading the text) that it is obsoleted by RFC 4288.

People reading http://tools.ietf.org/html/rfc2048 know that it's been
obsoleted, but the plain text versions don't have the forward link.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms030104080205050903090606
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms030104080205050903090606--

Date: Fri, 17 Jun 2011 17:00:01 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Peter Saint-Andre <[email-masked]>
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] outdated template (was: Re: Review requested for draft-ietf-sidr-repos-struct)
Reply-To: Chris Lilley <[email-masked]>

On Friday, June 17, 2011, 4:52:23 PM, Peter wrote:

PSA> On 6/17/11 7:22 AM, Bjoern Hoehrmann wrote:
>> * Stewart Bryant wrote:
>>> 7.1.1.  application/rpki-manifest

>>>    MIME media type name:  application
>>>    MIME subtype name:  rpki-manifest

>> This uses an outdated template, the current template is in RFC 4288.

PSA> Bjoern, I notice that many of your reviews start with "this uses an
PSA> outdated template". Do we need to update pointers somewhere so that
PSA> people know which template to use?

People reading RFC 4288  know
a) which template to use
b) that it obsoletes RFC 2048

People reading RFC 2048 think they know
a) which template to use

and they know that it obsoletes some older RFCs but don't know (from reading the text) that it is obsoleted by RFC 4288.

I have seen a checker for documents, to make sure the referenced RFCs are up to date; is there a tool (that doesn't start with a document), to see if a single RFC is the latest?

Also, I assume its a policy decision that RFCs once published are never updated to say that they are obsoleted; but perhapsit is time to review that decision? I imagine most people consult an online copy nowadays rather than taking out a dusty pile of lineprinter paper to read.

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Date: Fri, 17 Jun 2011 08:52:23 -0600
From: Peter Saint-Andre <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: [ietf-types] outdated template (was: Re: Review requested for draft-ietf-sidr-repos-struct)

This is a cryptographically signed message in MIME format.

--------------ms050701020602040503040303
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/17/11 7:22 AM, Bjoern Hoehrmann wrote:
> * Stewart Bryant wrote:
>> 7.1.1.  application/rpki-manifest
>>
>>    MIME media type name:  application
>>    MIME subtype name:  rpki-manifest
>=20
> This uses an outdated template, the current template is in RFC 4288.

Bjoern, I notice that many of your reviews start with "this uses an
outdated template". Do we need to update pointers somewhere so that
people know which template to use?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms050701020602040503040303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms050701020602040503040303--

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Fri, 17 Jun 2011 15:22:01 +0200
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

* Stewart Bryant wrote:
>7.1.1.  application/rpki-manifest
>
>    MIME media type name:  application
>    MIME subtype name:  rpki-manifest

This uses an outdated template, the current template is in RFC 4288.

>    Required parameters:  None
>    Optional parameters:  None
>    Encoding considerations:  binary
>    Security considerations:  Carries a RPKI Manifest
>       [I-D.ietf-sidr-rpki-manifests].

This should perhaps reference the Security Considerations of that
document then.

>    Interoperability considerations:  None
>    Published specification:  This document
>    Applications which use this media type:  Any MIME-complaint transport

This should say something more like "3D Modeling Software".

(Same comments apply to the other type.)
-- 
Björn Höhrmann · mailto:[email-masked] · 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/ 

Date: Fri, 17 Jun 2011 14:14:52 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [ietf-types] Review requested for draft-ietf-sidr-repos-struct
Reply-To: [email-masked]

draft-ietf-sidr-repos-struct

https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/

Makes the following types request.

Review comments by 1 July would be appreciated.

Many thanks

- Stewart

7.1.1.  application/rpki-manifest

    MIME media type name:  application
    MIME subtype name:  rpki-manifest
    Required parameters:  None
    Optional parameters:  None
    Encoding considerations:  binary
    Security considerations:  Carries a RPKI Manifest
       [I-D.ietf-sidr-rpki-manifests].
    Interoperability considerations:  None
    Published specification:  This document
    Applications which use this media type:  Any MIME-complaint transport
    Additional information:
       Magic number(s):  None
       File extension(s):  .mft
       Macintosh File Type Code(s):
    Person&  email address to contact for further information:  Geoff
       Huston<[email-masked]>
    Intended usage:  COMMON
    Author/Change controller:  Geoff Huston<[email-masked]>

7.1.2.  application/rpki-roa

    MIME media type name:  application>
    MIME subtype name:  rpki-roa
    Required parameters:  None
    Optional parameters:  None
    Encoding considerations:  binary
    Security considerations:  Carries a RPKI ROA
       [I-D.ietf-sidr-roa-format]
    Interoperability considerations:  None

Huston, et al.          Expires December 10, 2011              [Page 12]
Internet-Draft        ResCert Repository Structure             June 2011

    Published specification:  This document
    Applications which use this media type:  Any MIME-complaint transport
    Additional information:
       Magic number(s):  None
       File extension(s):  .roa
       Macintosh File Type Code(s):
    Person&  email address to contact for further information:  Geoff
       Huston<[email-masked]>
    Intended usage:  COMMON
    Author/Change controller:  Geoff Huston<[email-masked]>

From: "Michael Steidl \(IPTC\)" <[email-masked]>
To: <[email-masked]>
Date: Fri, 17 Jun 2011 13:39:07 +0200
Organization: IPTC
Subject: [ietf-types] Updating registration of application/vnd.iptc.g2.planningitem+xml

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01CC2CF3.EE489130
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Upon request a Windows Clipboard Flavor Name and a Macintosh Uniform =
Type Identifier have been added.

=20

This is the updated application:

=20

Media Type Name: application

=20

Subtype name: vnd.iptc.g2.planningitem+xml

=20

Required parameters: none

=20

Optional parameters: charset

identical to the charset parameter on application/xml as described

in RFC 3023 [RFC3023] section 3.2

=20

Encoding considerations: Identical to those of application/xml as

described in RFC 3023, section 3.2

=20

Security considerations: In regards to general XML Security issues,

identical to those of "application/xml" as described in RFC3023,

section 10. Beyond these general XML Security issues, the media

type does not contain active or executable content. The information

contained in the media type does not require privacy or integrity

services, however the media type does support the use of the XML

syntax and processing rules for creating and representing digital

signatures as described by RFC3275.

=20

Interoperability considerations:

=20

Published specification:

=20

for NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 =
specifications

=20

http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-C=
ore.xsd

=20

Or

=20

http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-P=
ower.xsd

=20

Applications which use this media type: none

=20

Additional information:

=20

Magic number(s): none

=20

File extension(s): .xml

=20

Macintosh File Type Code(s): Identical to those of

"application/xml" as described in RFC3023, "TEXT"

=20

Windows Clipboard Flavor Name: "IPTC PlanningItem XML"

=20

Macintosh Uniform Type Identifier: org.iptc.planningitem conforms to =
public.xml

=20

Object Identifier(s) or OID(s):

It must be possible to positively identify an Item as it moves

through the news workflow, and is transferred from place to place

and from system to system. An Item therefore gets a globally

unique identifier (guid), which is a persistent, universally unique

identifier, and a version which is incremented when the content of

the Item is updated. The first version is numbered 1: if the version

is not explicitly set, this value must be assumed by the recipient of

the Item. The guid is required to be in the form of a IRI. Any IRI

capable of acting as a globally unique identifier is accepted; the

IPTC provides a standard for this purpose in the form of an IETF RFC

[RFC-3085].

=20

Intended usage:

=20

A Planning Item conveys information for the editorial staff of

media companies about the planned coverage of events or topics=20

by a news provider.

Typically a Planning Item holds details like the headline,

keywords and the time of release for a set of planned News Items,

Concept Items or Package items. Further a Planning Item

may provide a list of already delivered Items.

=20

Other Information/General Comment: none

=20

Person to contact for further information:

Name: Michael Steidl

E-mail: [email-masked]

=20

Author/Change controller:

Name: Michael Steidl

E-mail: [email-masked]

=20

=20

=20

Michael Steidl

Managing Director of the IPTC [[email-masked]]

International Press Telecommunications Council=20
Web:  <http://www.iptc.org/> www.iptc.org - on Twitter  =
<http://www.twitter.com/IPTC> @IPTC

Business office address:=20

20 Garrick Street, London WC2E 9BT, United Kingdom

Registered in England, company no 101096

=20

------=_NextPart_000_0083_01CC2CF3.EE489130
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 12 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DDE-AT link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>U=
pon request a Windows Clipboard Flavor Name and a Macintosh Uniform Type =
Identifier have been added.<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>T=
his is the updated application:<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>M=
edia Type Name: application<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>S=
ubtype name: vnd.iptc.g2.planningitem+xml<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>R=
equired parameters: none<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>O=
ptional parameters: charset<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>i=
dentical to the charset parameter on application/xml as =
described<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>i=
n RFC 3023 [RFC3023] section 3.2<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>E=
ncoding considerations: Identical to those of application/xml =
as<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>d=
escribed in RFC 3023, section 3.2<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>S=
ecurity considerations: In regards to general XML Security =
issues,<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>i=
dentical to those of &quot;application/xml&quot; as described in =
RFC3023,<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>s=
ection 10. Beyond these general XML Security issues, the =
media<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>t=
ype does not contain active or executable content. The =
information<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>c=
ontained in the media type does not require privacy or =
integrity<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>s=
ervices, however the media type does support the use of the =
XML<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>s=
yntax and processing rules for creating and representing =
digital<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>s=
ignatures as described by RFC3275.<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I=
nteroperability considerations:<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>P=
ublished specification:<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>f=
or NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 =
specifications<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>h=
ttp://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Co=
re.xsd<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>O=
r<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>h=
ttp://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Po=
wer.xsd<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>A=
pplications which use this media type: none<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>A=
dditional information:<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>M=
agic number(s): none<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>F=
ile extension(s): .xml<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>M=
acintosh File Type Code(s): Identical to those =
of<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>&=
quot;application/xml&quot; as described in RFC3023, =
&quot;TEXT&quot;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>W=
indows Clipboard Flavor Name: &quot;IPTC PlanningItem =
XML&quot;<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>M=
acintosh Uniform Type Identifier: org.iptc.planningitem conforms to =
public.xml<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>O=
bject Identifier(s) or OID(s):<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I=
t must be possible to positively identify an Item as it =
moves<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>t=
hrough the news workflow, and is transferred from place to =
place<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>a=
nd from system to system. An Item therefore gets a =
globally<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>u=
nique identifier (guid), which is a persistent, universally =
unique<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>i=
dentifier, and a version which is incremented when the content =
of<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>t=
he Item is updated. The first version is numbered 1: if the =
version<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>i=
s not explicitly set, this value must be assumed by the recipient =
of<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>t=
he Item. The guid is required to be in the form of a IRI. Any =
IRI<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>c=
apable of acting as a globally unique identifier is accepted; =
the<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I=
PTC provides a standard for this purpose in the form of an IETF =
RFC<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>[=
RFC-3085].<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I=
ntended usage:<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>A=
 Planning Item conveys information for the editorial staff =
of<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>m=
edia companies about the planned coverage of events or topics =
<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>b=
y a news provider.<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>T=
ypically a Planning Item holds details like the =
headline,<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>k=
eywords and the time of release for a set of planned News =
Items,<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>C=
oncept Items or Package items. Further a Planning =
Item<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>m=
ay provide a list of already delivered Items.<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>O=
ther Information/General Comment: none<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>P=
erson to contact for further information:<o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>N=
ame: Michael Steidl<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>E=
-mail: [email-masked]<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>A=
uthor/Change controller:<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>N=
ame: Michael Steidl<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>E=
-mail: [email-masked]<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><=
o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>Michael Steidl<o:p></o:p></span></b></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>Managing Director of the IPTC =
[[email-masked]]<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>International Press Telecommunications Council <br>Web: </span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
><a href=3D"http://www.iptc.org/"><span lang=3DEN-GB =
style=3D'color:#1F497D'>www.iptc.org</span></a></span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
> <span lang=3DEN-GB>- on Twitter </span></span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
><a href=3D"http://www.twitter.com/IPTC"><span lang=3DEN-GB =
style=3D'color:#1F497D'>@IPTC</span></a></span><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
><o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>Business office address: <o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>20 Garrick Street, London WC2E 9BT, United =
Kingdom<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
>Registered in England, company no 101096<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DEN-GB><o:p>&nbsp;</o:p></span></p></div></body></html>
------=_NextPart_000_0083_01CC2CF3.EE489130--

Date: Thu, 16 Jun 2011 15:23:08 +0200
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

On 2011-06-14 17:18, Bjoern Hoehrmann wrote:
> Hi,
>
>    On http://www.ietf.org/id/draft-melnikov-mime-default-charset-00.txt
>
> The first paragraph is horrible. It fails to properly separate the RFC
> 2046 context from the RFC 2616 context, and instead makes encoding de-
> tection a property of the media type independently of context. That is

I think mentioning both here makes sense as RFC 2616 overrides the 
default set in 2046 (when used over HTTP).

> not how media types are used, it is common for instance to use them in
> contexts where a character encoding is not used at all, for instance,
> in a XHTML document with
>
>    <style type='text/css'>
>      ...
>    </style>
> ...

That's a good point. The same applies to <script> in (X)HTML, and AFAIR 
<atom:content>.

We should describe this use case somewhere, and point out that in cases 
like these, the charset parameter doesn't make sense.

Does this belong into *this* document, though?

 > ...

Best regards, Julian

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Jun 2011 00:40:32 +0200
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

On 15 June 2011 23:44, Bjoern Hoehrmann wrote:

> My point was that the context where the media type label
> and the content occur in is important. RFC 2616 did
> not "change the default", it spelled out rules for HTTP
> messages, which is a different context than what
> RFC 2046 was about.

IBTD, RFC 2616 has a reference to RFC 2046, and I think
that should be a "normative reference" in a modern RFC.

And unlike the old "HTML i18n" RFC the HTTP RFC already
knew BCP 18 (listed in the references).  In other words,
it ignored MIME *and* the IETF charset policy for its
own purposes (= compatibilty with existing software at
the time of its publication).

[...]
> Right now the model is that higher level information
> overrides lower-level information, so the server
> administrator wins over the content maintainer. That's
> a bad model as information about encodings, media
> types, is not stored in typical file systems, and
> cannot be conveyed through some protocols, so explicit
> out of band configuration is required, but that's what
> we have got at the moment. That's not likely to change
> for old protocols.

Yes, that's what I meant.  The most specific info should
win, not the most general (server) info.  If exactly the
same resource is also available by FTP it could be valid
for FTP, and invalid for HTTP.  That is not only "bad",
it is plain wrong:  Hopefully HTTPbis fixes this, or at
least documents the fact of its own "unusabilty" for many
users unable to configure Web servers of a third party,
i.e., their Web hoster.

> I am saying that the draft maybe should specify "don't
> know" as that reflects reality fairly well.

Well, the MIME default is a last resort for "dunno", one
step before you are forced to sniff and guess.  Charset
sniffing does not work well for UTF-8 vs. ASCII-based
SBCS, if non-ASCII bytes occur too late in text/plain.

> I do understand that people think, and quite rightly
> so, that you "need" to know the encoding, but that does
> not mean the protocols must specify an answer even if
> that does not correspond to reality.

And that is the problem that has to be fixed for HTTPbis.
If the solution is "don't talk about it, use a normative
reference to MIME, and decree that the old ISO-8859-1
default turned out to be a bad idea" I'd like it better
than what we have now in RFC 2616.

Sadly this business also affects AUTH DIGEST, and it was
one of several reasons why SASL DIGEST was obsoleted.

The HTTP DIGEST RFC inherited the obscure HTTP default
charset.  From there this beast spread out, AUTH DIGEST
(ignoring the now potentially obsolete SASL DIGEST) is
used in other protocols, I vaguely recall "SIPPING".

> RFC 3023 specifies that text/xml "is" US-ASCII even
> though RFC 2616 says it "is" ISO-8859-1, that is
> probably what you mean here.

Yes, when a text/xml resource clearly states that it is
UTF-8 it shouldn't be rejected as invalid by validators
only because a server or browser transmitted the file
as text/plain.

This mess was caused by not strictly following MIME in
other RFCs.  Nothing is wrong with MIME -- other RFCs
trying to outsmart MIME failed miserably, and caused
unnecessary pains for many authors trying to create
"valid" documents.

-Frank

From: Bjoern Hoehrmann <[email-masked]>
To: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2011 23:44:19 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

* Frank Ellermann wrote:
>Sorry, you lost me here, inline CSS as in your example uses
>the document charset, doesn't it?  You can certainly have
>non-ASCII in CSS comments or in, say, CSS "content" values.
>
>For external CSS files the charset can be specified inline
>with, e.g., @charset "us-ascii"; (begin of file).  Please
>correct me if I'm wrong, my CSS knowledge is very limited.
>
>I'd be surprised if the charset for inline CSS could be
>different from the document charset -- if that's what you
>are talking about it's IMO obvious, but maybe the new I-D
>should mention the issue of "an immutable per document
>default for inline text/css or text/javascript".

Your understanding above is correct. My point was that the context where
the media type label and the content occur in is important. RFC 2616 did
not "change the default", it spelled out rules for HTTP messages, which
is a different context than what RFC 2046 was about.

>Sounds good.  Hopefully inline definitions maintained by
>the authors of resources can overrule whatever server
>admins configure, unlike server admins the authors should
>know which charset they use.

(I am not sure what you are saying here. Right now the model is that
higher level information overrides lower-level information, so the
server administrator wins over the content maintainer. That's a bad
model as information about encodings, media types, is not stored in
typical file systems, and cannot be conveyed through some protocols,
so explicit out of band configuration is required, but that's what we
have got at the moment. That's not likely to change for old protocols.)

>> for text/plain, and for many other subtypes, if there is
>> no charset parameter, then you don't know what encoding
>> it is in.
>
>Of course you know this, because MIME specifies US-ASCII.

I am saying that the draft maybe should specify "don't know" as that
reflects reality fairly well. I do understand that people think, and
quite rightly so, that you "need" to know the encoding, but that does
not mean the protocols must specify an answer even if that does not
correspond to reality.

>Other text/* types I'm aware of (text/xml, text/html,
>text/css) permit this to some degree -- but there was
>something special with text/xml, I forgot the details;
>was it perhaps "text/xml MUST be US-ASCII"?

RFC 3023 specifies that text/xml "is" US-ASCII even though RFC 2616
says it "is" ISO-8859-1, that is probably what you mean here.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/ 

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2011 23:27:47 +0200
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

On 14 June 2011 17:18, Bjoern Hoehrmann wrote:

> it is common for instance to use them in contexts where a
> character encoding is not used at all, for instance, in a
> XHTML document with

> =A0<style type=3D'text/css'>
> =A0 =A0...
> =A0</style>

> there is no value used for the absent charset parameter,
> it's a notion that does not make sense in the context.

Sorry, you lost me here, inline CSS as in your example uses
the document charset, doesn't it?  You can certainly have
non-ASCII in CSS comments or in, say, CSS "content" values.

For external CSS files the charset can be specified inline
with, e.g., @charset "us-ascii"; (begin of file).  Please
correct me if I'm wrong, my CSS knowledge is very limited.

I'd be surprised if the charset for inline CSS could be
different from the document charset -- if that's what you
are talking about it's IMO obvious, but maybe the new I-D
should mention the issue of "an immutable per document
default for inline text/css or text/javascript".

> a protocol similar to HTTP where all text/* is transported
> UTF-16 encoded which would result in a similar situation.

Now I'm confused, the HTTP default is ISO-8859-1, and that
is precisely what has to be fixed a.s.a.p.  As far as I'm
concerned US-ASCII also for HTTP is a solution; the HTML5
proposal "interpret ISO-8859-1 as windows-1252" is an odd
hack, but better than nothing; and more radical "let's just
say UTF-8 and be done with it" ideas didn't make it on the
HTTPbis list three years ago.

Are you talking about a hypothetical protocol with its own
UTF-16 default for text/*?  I'm not aware of any protocol
violating MIME for its purposes, only HTTP has this issue,
and the draft apparently tries to fix this.

> The default of US-ASCII is for the text/plain type.

No, already answered by Julian.  As you said RFC 2046 is
not a new RFC, and it should be updated to use the new
ABNF STD when the message format and SMTP RFCs are finally
full Internet standards (insert "errata exist" blurb here).

But just because the MIME RFC is old doesn't mean that it
is wrong, a compliment I would not extend to HTTP.  Maybe
the draft should get an i18n section as mandated by the
IETF charset policy, and explain why UTF-8 is *not* the
default for historical reasons (and practical reasons
wrt to old mail software not "yet" supporting 8BITMIME).

> "This memo changes RFC 2046 by defining and clarifying
>  rules how to determine the character encoding of
>  resources labeled with a text subtype."

Sounds good.  Hopefully inline definitions maintained by
the authors of resources can overrule whatever server
admins configure, unlike server admins the authors should
know which charset they use.

> for text/plain, and for many other subtypes, if there is
> no charset parameter, then you don't know what encoding
> it is in.

Of course you know this, because MIME specifies US-ASCII.

It could end up as UNKNOWN-8BIT (registered by IANA) if
the US-ASCII theory fails miserably, but that is another
story.  The text/plain case is a special case, because
there is no standard way to note the document charset
within the document -- or rather, I'm not aware of any
standard apart from Unicode "BOM" signatures, or the old
and forgotten ISO charset escape-sequences.

Other text/* types I'm aware of (text/xml, text/html,
text/css) permit this to some degree -- but there was
something special with text/xml, I forgot the details;
was it perhaps "text/xml MUST be US-ASCII"?

-Frank

Date: Wed, 15 Jun 2011 00:15:24 +0200
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

On 2011-06-15 00:13, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> On 2011-06-14 17:18, Bjoern Hoehrmann wrote:
>>> ...
>>> There is also confusion about what RFC 2046 specifies. The default of
>>> US-ASCII is for the text/plain type. While there are suggestions that it
>>> ...
>>
>> No, it *really* applies to text/*.
>>
>> See
>> <http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.1.2.p.18>
>> -- that's in the section 4.1.2 (Charset Parameter), not in 4.1.3 (Plain
>> Subtype).
>
> It's easy to get caught up on archaeological details like this, here I
> might argue that this is for the Content-Type header in "Internet mail",
> but as I noted, I do not think it's valuable to overanalyze what some
> specification may have meant to specify 15 years ago. As I understand
> it, the idea of the draft is come up with something coherent to replace
> what's in there. I would prefer to keep the draft and the discussion as
> close as possible to "This whole charset, content-type, mail vs http,
> stuff sucks, but we are fixing this now saying X".

I'm not disagreeing.

On the other hand, it's necessary that we agree on what needs to be 
fixed; and this certainly is something that does not to be fixed...

Best regards, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 00:13:58 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

* Julian Reschke wrote:
>On 2011-06-14 17:18, Bjoern Hoehrmann wrote:
>> ...
>> There is also confusion about what RFC 2046 specifies. The default of
>> US-ASCII is for the text/plain type. While there are suggestions that it
>> ...
>
>No, it *really* applies to text/*.
>
>See 
><http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.1.2.p.18> 
>-- that's in the section 4.1.2 (Charset Parameter), not in 4.1.3 (Plain 
>Subtype).

It's easy to get caught up on archaeological details like this, here I
might argue that this is for the Content-Type header in "Internet mail",
but as I noted, I do not think it's valuable to overanalyze what some
specification may have meant to specify 15 years ago. As I understand
it, the idea of the draft is come up with something coherent to replace
what's in there. I would prefer to keep the draft and the discussion as
close as possible to "This whole charset, content-type, mail vs http,
stuff sucks, but we are fixing this now saying X".
-- 
Björn Höhrmann · mailto:[email-masked] · 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/ 

Date: Wed, 15 Jun 2011 00:00:25 +0200
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

On 2011-06-14 17:18, Bjoern Hoehrmann wrote:
> ...
> There is also confusion about what RFC 2046 specifies. The default of
> US-ASCII is for the text/plain type. While there are suggestions that it
> ...

No, it *really* applies to text/*.

See 
<http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.1.2.p.18> 
-- that's in the section 4.1.2 (Charset Parameter), not in 4.1.3 (Plain 
Subtype).

Best regards, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Tue, 14 Jun 2011 17:18:17 +0200
Subject: [ietf-types] Comments on draft-melnikov-mime-default-charset-00.txt

Hi,

  On http://www.ietf.org/id/draft-melnikov-mime-default-charset-00.txt

The first paragraph is horrible. It fails to properly separate the RFC
2046 context from the RFC 2616 context, and instead makes encoding de-
tection a property of the media type independently of context. That is
not how media types are used, it is common for instance to use them in
contexts where a character encoding is not used at all, for instance,
in a XHTML document with

  <style type='text/css'>
    ...
  </style>

there is no value used for the absent charset parameter, it's a notion
that does not make sense in the context. Similarily, I might make a
protocol similar to HTTP where all text/* is transported UTF-16 encoded
which would result in a similar situation. Even if that protocol had a
Content-Type header and allowed media type parameters, the charset para-
meter would have no influence on the bytes-to-text mapping.

There is also confusion about what RFC 2046 specifies. The default of
US-ASCII is for the text/plain type. While there are suggestions that it
"kinda" applies to other sub-types, for instance, like when handling an
unrecognized subtype, it should be handled like "plain", the language in
RFC 2046 leaves room for much interpretation and running code often does
not follow a particular interpretation like the one in the draft.

I think this should all be something more like "This memo changes RFC
2046 by defining and clarifying rules how to determine the character
encoding of resources labeled with a text subtype." and then say little
about the various sources of disputes and confusion.

In section 3 the notion that you always get to know the encoding, as is
implied by, for instance, "i.e. the charset information is transport
inside the payload", does not reflect current practise. Look, for text/
plain, and for many other subtypes, if there is no charset parameter,
then you don't know what encoding it is in. Maybe there are internal
markers, maybe there are not. Some formats do not even care, it's common
for "source code" for instance to just care about some special bytes and
ignore or pass verbatim the rest; some allow to mix encodings.

It seems to me the rules should rather be something like:

  1. If there is a higher-level protocol with rules, those rules win.

  2. If there is a charset parameter but it's malformed: out of scope.

  3. If there is a properly formed charset parameter, that wins. That
     wins even if the encoding is unsupported and there are other hints
     inside the document. That wins for all text subtypes, always.

  4. Otherwise it's type-specific and if the type specification does
     not define how you determine the encoding in this case, you don't
     know what the encoding is. For text/plain in particular, you do
     not know, it's not US-ASCII, you don't know.

I don't see why you would not define it this way, it sets expectations
reasonably well while also being relatively simple. There is no utility
for instance in having some text types that do not use the charset pa-
rameter at this level. You may very well have a format that just says it
is always UTF-8, but when you add charset=iso-8859-1 then some will take
the charset parameter as authoriative, possibly due to text/plain de-
faulting, so you get confusion and security vulnerabilities.

What should happen in a case like that is that the receiving software
recognizes the presence of a charset parameter with an encoding that is
not expected, like in the example, as indicating corruption and maybe a
deliberate attack against the system and respond as appropriate. It's a
bad idea to simply ignore the charset parameter and essentially hope the
other components of the system handle the situation safely even as they
are updated and replaced over time.

Leaving the US-ASCII default as-is seems rather silly even, there is so
much non-ASCII text/plain content without a proper label out there, it's
without informational value to say the default is US-ASCII beyond saying
not including a charset parameter is probably a bad idea (but plenty of
people do it anyway).

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · 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/ 

From: "Carl Reed" <[email-masked]>
To: "Paul Libbrecht" <[email-masked]>
Date: Fri, 3 Jun 2011 16:27:43 -0600
Cc: [email-masked], Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] Registration of media type gml+xml (by the Open Geospatial Consortium)

Paul -

Thanks for the feedback. Let be pass on your suggestion to the OGC GML 
community.

Regards

Carl

----- Original Message ----- 
From: "Paul Libbrecht" <[email-masked]>
To: "Carl Reed" <[email-masked]>
Cc: "Bjoern Hoehrmann" <[email-masked]>; <[email-masked]>
Sent: Friday, June 03, 2011 4:26 PM
Subject: Re: [ietf-types] Registration of media type gml+xml (by the Open 
Geospatial Consortium)

Carl,

Could I suggest that the additional information section is enriched with 
recommended flavor names for the Windows and MacOSX operating systems?

At first glance, I would suggest the following:
- Windows Clipboard Name: OGC GML
- Macintosh Universal Type Identifier code: public.gml conforming to 
public.xml

This way, interoperability can be done at the clipboard. Do I mistake or the 
clipboard sounds to be a fairly good place to put, say, a location or route 
you have selected and copied in one application and want to paste into 
another?

thanks in advance

Paul

Le 3 juin 2011 à 23:47, Carl Reed a écrit :

> Bjoern and the ietf-types list -
>
> I have coordinated with Clemens Portele on a revision to the contents of 
> the submission. Please find below my signature a revision to the 
> registration request for a media type gml+xml (by the Open Geospatial 
> Consortium)
>
> I also checked to make sure that we are using the correct template as 
> specified in RFC 4288. I will update the version as uploaded to 
> datatracker.
>
> Regards
>
> Carl Reed, PhD
> CTO
> Open Geospatial Consortium
>
>
> 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
>
>
>
>
> ----- Original Message ----- From: "Bjoern Hoehrmann" <[email-masked]>
> To: "Carl Reed" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 01, 2011 12:34 PM
> Subject: Re: [ietf-types] Registration of media type -gml+xml (by the Open 
> Geospatial Consortium)
>
>
>> * Carl Reed wrote:
>>> MIME media type name: Application
>>
>> This seems to be using an outdated template. The current template is in
>> RFC 4288, there are some minor differences like this field name. New re-
>> gistrations should follow the most recent template.
>>
>>> MIME subtype name:    Standards Tree -gml+xml
>>
>> The value should be "gml+xml" if this' to register application/gml+xml.
>>
>>> 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".
>>
>> (I think this is insufficient, for instance, it is not clear whether
>> you can use version=3.2 and also version="3.2" but many registrations
>> have this problem.)
>> -- 
>> Björn Höhrmann · mailto:[email-masked] · 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/
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Paul Libbrecht <[email-masked]>
Date: Sat, 4 Jun 2011 00:26:08 +0200
To: Carl Reed <[email-masked]>
Cc: [email-masked], Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] Registration of media type gml+xml (by the Open Geospatial Consortium)

Carl,

Could I suggest that the additional information section is enriched with =
recommended flavor names for the Windows and MacOSX operating systems?

At first glance, I would suggest the following:
- Windows Clipboard Name: OGC GML
- Macintosh Universal Type Identifier code: public.gml conforming to =
public.xml

This way, interoperability can be done at the clipboard. Do I mistake or =
the clipboard sounds to be a fairly good place to put, say, a location =
or route you have selected and copied in one application and want to =
paste into another?

thanks in advance

Paul

Le 3 juin 2011 =E0 23:47, Carl Reed a =E9crit :

> Bjoern and the ietf-types list -
>=20
> I have coordinated with Clemens Portele on a revision to the contents =
of the submission. Please find below my signature a revision to the =
registration request for a media type gml+xml (by the Open Geospatial =
Consortium)
>=20
> I also checked to make sure that we are using the correct template as =
specified in RFC 4288. I will update the version as uploaded to =
datatracker.
>=20
> Regards
>=20
> Carl Reed, PhD
> CTO
> Open Geospatial Consortium
>=20
>=20
> Type name: Application
>=20
> Subtype name: Standards Tree gml+xml
>=20
> Required parameters:  None
>=20
> 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]
>=20
>  "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".
>=20
>  The value may be provided with or without quotes. i.e.,
>  application/gml+xml; version=3D3.1 shall be treated as identical to
>  application/gml+xml; version=3D"3.1".
>=20
>  In cases where elements from multiple GML versions are used,
>  the parameter shall indicate the highest GML version used in the
>  document.
>=20
>  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.
>=20
> Encoding considerations: As per Section 3.2 of [RFC3023]
>=20
> 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.
>=20
>  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.
>=20
> 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.
>=20
> 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.
>=20
>  The OGC GML MIME specification has also been approved by the OGC
>  Membership and is published here:
>  http://portal.opengeospatial.org/files/?artifact_id=3D37743
>=20
> 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.
>=20
> Additional information:
>=20
> 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
>=20
>   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.
>=20
> Person & email address to contact for further information:
>=20
>   Name : Clemens Portele
>   Address:Interactive Instruments, Bonn, Germany
>   Email : [email-masked]
>=20
> Intended usage: Common
>=20
> Restrictions on usage:
>   None
>=20
> 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.
>=20
>   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=3D23325
>=20
>=20
>=20
>=20
> ----- Original Message ----- From: "Bjoern Hoehrmann" =
<[email-masked]>
> To: "Carl Reed" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 01, 2011 12:34 PM
> Subject: Re: [ietf-types] Registration of media type -gml+xml (by the =
Open Geospatial Consortium)
>=20
>=20
>> * Carl Reed wrote:
>>> MIME media type name: Application
>>=20
>> This seems to be using an outdated template. The current template is =
in
>> RFC 4288, there are some minor differences like this field name. New =
re-
>> gistrations should follow the most recent template.
>>=20
>>> MIME subtype name:    Standards Tree -gml+xml
>>=20
>> The value should be "gml+xml" if this' to register =
application/gml+xml.
>>=20
>>> Optional parameters:
>>>=20
>>>  "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".
>>=20
>> (I think this is insufficient, for instance, it is not clear whether
>> you can use version=3D3.2 and also version=3D"3.2" but many =
registrations
>> have this problem.)
>> --=20
>> Bj=F6rn H=F6hrmann =B7 mailto:[email-masked] =B7 =
http://bjoern.hoehrmann.de
>> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
>> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/
>=20
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: "Carl Reed" <[email-masked]>
To: "Bjoern Hoehrmann" <[email-masked]>
Date: Fri, 3 Jun 2011 15:47:55 -0600
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type gml+xml (by the Open Geospatial Consortium)

Bjoern and the ietf-types list -

I have coordinated with Clemens Portele on a revision to the contents of the 
submission. Please find below my signature a revision to the registration 
request for a media type gml+xml (by the Open Geospatial Consortium)

I also checked to make sure that we are using the correct template as 
specified in RFC 4288. I will update the version as uploaded to datatracker.

Regards

Carl Reed, PhD
CTO
Open Geospatial Consortium

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

----- Original Message ----- 
From: "Bjoern Hoehrmann" <[email-masked]>
To: "Carl Reed" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 01, 2011 12:34 PM
Subject: Re: [ietf-types] Registration of media type -gml+xml (by the Open 
Geospatial Consortium)

>* Carl Reed wrote:
>>MIME media type name: Application
>
> This seems to be using an outdated template. The current template is in
> RFC 4288, there are some minor differences like this field name. New re-
> gistrations should follow the most recent template.
>
>>MIME subtype name:    Standards Tree -gml+xml
>
> The value should be "gml+xml" if this' to register application/gml+xml.
>
>>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".
>
> (I think this is insufficient, for instance, it is not clear whether
> you can use version=3.2 and also version="3.2" but many registrations
> have this problem.)
> -- 
> Björn Höhrmann · mailto:[email-masked] · 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/
> 

From: Bjoern Hoehrmann <[email-masked]>
To: "Carl Reed" <[email-masked]>
Date: Wed, 01 Jun 2011 20:34:38 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type -gml+xml (by the Open Geospatial Consortium)

* Carl Reed wrote:
>MIME media type name: Application

This seems to be using an outdated template. The current template is in
RFC 4288, there are some minor differences like this field name. New re-
gistrations should follow the most recent template.

>MIME subtype name:    Standards Tree -gml+xml

The value should be "gml+xml" if this' to register application/gml+xml.

>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".

(I think this is insufficient, for instance, it is not clear whether
you can use version=3.2 and also version="3.2" but many registrations
have this problem.)
-- 
Björn Höhrmann · mailto:[email-masked] · 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/ 

From: "Carl Reed" <[email-masked]>
To: <[email-masked]>
Date: Wed, 1 Jun 2011 10:25:17 -0600
Subject: [ietf-types] Registration of media type -gml+xml (by the Open Geospatial Consortium)

This is a multi-part message in MIME format.

------=_NextPart_000_0343_01CC2046.33DB9590
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To whom it may concern -

The OGC is an international standards organization focused on encoding =
and interface standards for use in the geospatial and locations services =
domains. One of out most widely implemented standards is the Geography =
Markup Language (GML). Recently, the GML implementation community has =
identifed the need for a GML MIME type. Below my signature is the =
information on the GML MIME type for your review and consideration. The =
long version of this document may be found at: =
http://www.ietf.org/internet-drafts/draft-portele-ogc-gml-mime-01.txt

Thank you for your time and consideration.

Regards

Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org

Name: Carl Reed

=20

Email: [email-masked]

=20

MIME media type name: Application

=20

MIME subtype name:    Standards Tree -gml+xml

=20

Required parameters:  None

=20

Optional parameters:

   "charset" The charset parameter of application/gml+xml is=20

   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=20

   version used in the GML document. Only the major and=20

   the first minor version number are provided, e.g. "3.2".

=20

Encoding considerations: As per Section 3.2 of [RFC3023]

=20

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.

=20

   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.

=20

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.

=20

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 online at

   http://www.opengeospatial.org/standards/gml.

=20

The OGC GML MIME specification has also been approved by the OGC

   Membership and is published here:

   http://portal.opengeospatial.org/files/?artifact_id=3D37743

=20

Applications which use this media:

   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.

=20

Additional information:

=20

 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

=20

    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.

=20

 Person to contact for further information :

=20

    Name : Clemens Portele

    Address:Interactive Instruments, Bonn, Germany

    Email : [email-masked]

=20

 Intended usage: Common

=20

 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.

=20

      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=3D23325

Carl Reed, PhD
CTO and Executive Director Specification 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=20
"Security is mostly a superstition. It does not exist in nature. Life is =
either a daring adventure or nothing." -- Helen Keller 
------=_NextPart_000_0343_01CC2046.33DB9590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.17037" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>To whom it may concern -</DIV>
<DIV>&nbsp;</DIV>
<DIV>The OGC is an international standards organization focused on =
encoding and=20
interface standards for use in the geospatial and locations services =
domains.=20
One of out most widely implemented standards is the Geography Markup =
Language=20
(GML). Recently, the GML implementation community has identifed the need =
for a=20
GML MIME type. Below my signature is the information on the GML MIME =
type for=20
your review and consideration. The long version of this document may be =
found=20
at: <A=20
href=3D"http://www.ietf.org/internet-drafts/draft-portele-ogc-gml-mime-01=
.txt">http://www.ietf.org/internet-drafts/draft-portele-ogc-gml-mime-01.t=
xt</A><BR></DIV>
<DIV>Thank you for your time and consideration.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>Carl Reed, PhD<BR>CTO and Executive Director Specification =
Program<BR>Open=20
Geospatial Consortium<BR><A=20
href=3D"http://www.opengeospatial.org/">www.opengeospatial.org</A></DIV><=
/DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Name: Carl Reed<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Email:=20
[email-masked]<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">MIME media type name:=20
Application<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">MIME subtype name:<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>Standards Tree=20
-gml+xml<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Required parameters:<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>None<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Optional =
parameters:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>=93charset=94=20
The charset parameter of application/gml+xml is=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>handled=20
in the same fashion as for application/xml, as=20
specified<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>in=20
Section 3.2 of [RFC3023]<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>"version": If provided, this parameter indicates the GML=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>version=20
used in the GML document. Only the major and=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>the first=20
minor version number are provided, e.g.=20
"3.2".<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Encoding considerations: As per Section 3.2 of=20
[RFC3023]<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Security =
considerations:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>The OGC=20
Geography Markup Language (GML) is a generic format=20
for<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>exchanging geographic information, but application designers=20
must<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>not=20
assume that it provides generic protection against=20
security<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>threats.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>RFC 3023, =
section=20
10, discusses security concerns for<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>generic=20
XML, which are also applicable to =
GML.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>Xlink=20
references in GML documents may cause arbitrary URIs to=20
be<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>dereferenced. In this case, the security issues of RFC=20
3986,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>section=20
7, should be considered.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Interoperability=20
considerations:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>Different=20
versions of GML specify different XML Schema documents=20
used<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>for the=20
validation of GML documents. Starting with version 3.2,=20
the<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>GML=20
version information is represented in the namespace.=20
As<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>applications may only support a subset of all published=20
GML<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>versions,=20
the use of the version parameter is=20
recommended.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Published specification =
:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>GML=20
(Geography Markup Language) is an international=20
standard<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>adopted=20
by both the Open Geospatial Consortium (OGC)=20
and<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>International Organization for Standardization (ISO). The=20
latest<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>version at the time of this =
writing is=20
3.2.1 which is published by<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>ISO as=20
ISO 19136:2007. The standard can be accessed online=20
at<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>http://www.opengeospatial.org/standards/gml.<o:p></o:p></FONT></FO=
NT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">The OGC GML MIME specification has also been =
approved by the=20
OGC<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Membership and is published=20
here:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>http://portal.opengeospatial.org/files/?artifact_id=3D37743<o:p></=
o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Applications which use this=20
media:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>GML is a=20
generic device-, platform-, and vendor-neutral=20
XML<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>grammar=20
and is supported by a range of applications=20
creating,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>providing=20
access to and processing geographic information. The=20
use<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>of GML is=20
in use internationally with hundreds of=20
deployed<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>applications able to create and ingest GML payloads, including=20
all<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>of the=20
major GIS vendors, many database providers, earth=20
browzer<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN>applications, and so forth.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">Additional =
information:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-fareast-font-family: 'MS =
Mincho'"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>1. Magic number(s):<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>None. =
</SPAN>Although no=20
byte sequences can be<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-bidi-font-size: 12.0pt"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>counted on to =
consistently=20
identify GML documents, GML<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>documents will have the sequence=20
http://www.opengis.net/gml<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp; </SPAN>as=20
part of a namespace declaration to identify the =
GML<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>namespace. This will usually be towards the top of the =
document.<SPAN=20
style=3D"mso-fareast-font-family: 'MS =
Mincho'"><o:p></o:p></SPAN></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>2. =
File=20
extension(s): .xml or .gml<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>3. =
Macintosh=20
file type code: TEXT<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>4. =
Object=20
Identifiers: None<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp; </SPAN>The=20
OGC is an international voluntary consensus=20
standards<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>organization focused on defining and maintaining standards=20
that<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>enable interoperability for using geospatial content and=20
services<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp; </SPAN>in=20
any application that requires the use of geospatial content=20
or<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>services. The OGC website is=20
www.opengeospatial.org.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN>Person to=20
contact for further information :<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Name : Clemens Portele<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Address:Interactive Instruments, Bonn,=20
Germany<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Email :=20
[email-masked]<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt; mso-outline-level: =
1"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN>Intended usage:=20
Common<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN>Author/Change=20
controller:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>The =
GML standard=20
is a work product of the Open =
Geospatial<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Consortium=20
(OGC). The OGC and the GML Standards =
Working<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Group =
have=20
change control over the GML =
standard.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New">&nbsp;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>MIME =
types for=20
use in OGC standards and formats are =
defined<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>by the =
OGC=20
Members and discussed and approved by the=20
OGC<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Naming =
Authority=20
(OGC-NA). The function and role of the=20
OGC-NA<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>is =
described in=20
RFC 5165 and in the OGC Policies and=20
Procedures<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'"><FONT size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>here: =
<A=20
href=3D"http://portal.opengeospatial.org/files/?artifact_id=3D23325">http=
://portal.opengeospatial.org/files/?artifact_id=3D23325</A><o:p></o:p></F=
ONT></FONT></SPAN></P></DIV>
<DIV>&nbsp;</DIV>
<DIV>Carl Reed, PhD<BR>CTO and Executive Director Specification =
Program<BR>Open=20
Geospatial Consortium<BR><A=20
href=3D"http://www.opengeospatial.org">www.opengeospatial.org</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>The OGC: Making Location Count!</DIV>
<DIV>&nbsp;</DIV>
<DIV>---------------------</DIV>
<DIV>&nbsp;</DIV>
<DIV>This communication, including attachments, is for the exclusive use =
of=20
addressee and may contain proprietary, confidential or privileged =
information.=20
If you are not the intended recipient, any use, copying, disclosure,=20
dissemination or distribution is strictly prohibited. If you are not the =

intended recipient, please notify the sender&nbsp; immediately by return =
email=20
and delete this communication and destroy all copies.</DIV>
<DIV>&nbsp;</DIV>
<DIV>"The important thing is not to stop questioning." -- Albert =
Einstein=20
<BR>"Security is mostly a superstition. It does not exist in nature. =
Life is=20
either a daring adventure or nothing." -- Helen Keller =
</DIV></BODY></HTML>

------=_NextPart_000_0343_01CC2046.33DB9590--