Subject: Re: [ietf-types] Registration of media type application/opensearchdescription+xml
From: Frank Ellermann <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: IANA MIME types <[email-masked]>
Date: Tue, 25 Oct 2011 17:10:16 +0200
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On 25 October 2011 08:54, Paul Libbrecht wrote:

> I hope someone will review the formal aspects of the
> procedure.

RFC 4288 guarantees an IETF Last Call for this beast if
it ever gets this far.  I've tried to submit an updated
"not for RFC" Internet Draft, but that's still stuck in
a manual submission queue.

RFC 4288 also guarantees (or rather demands) a complete
copy of the registration template in whatever passes as
specification, RFC or otherwise:

<URL:http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_5#MIME_type_application.2Fopensearchdescription.2Bxml>

Content and/or URL might change during the review here.

The OpenSearch folks suggested to replace OSDD by OSD,
and to add ".osdx" as the conventional file extension:
Microsoft uses ".osdx".

I'm not interested to "invent" wild + wonderful features,
I'm only interested to get this beast registered "as is".

> My usual suggestion is: what about clipboards?

Dunno, is there any problem with XML and clipboards?

> OpenSearch Description Documents sound to be a natural
> candidate to be exchanged in clipboards (be copied-and
> -pasted, be drag-and-dropped, ...). Do I mistake?

All I ever wish to do with OSDs is (1) edit some details,
or wrt the security considerations inspect their source,
(2) adopt an OSD when the auto-detect link rel="search"
worked as it should, (3) click on an AddSearchProvider()
EcmaScript link for cases where link rel="search" is no
option.  Where do clipboards enter this picture for you,
and is it relevant for the IANA media type registration?

> - Macintosh Uniform Type Identifier:
> org.opensearch.description conforms to public.xml

Sadly I've no idea how Mac Uniform type identifiers work,
and the info published in RFC 4288 convinced me that it's
not something to worry about.  If you have any "official"
public source that this is a well-known Mac id. I add it,
otherwise I prefer to stick to what I could defend in an
IETF Last Call.

> My guts feelings about the "responsibility" part of the > registration is that it lacks a tiny bit of formality:
> - isn't the WhatWG HTML a "place" for drafting a format > that will hopefully end up be a W3C standard?

AddSearchProvider() is documented in WhatWG HTML.  Both
the HTML5 draft and WhatWG HTML have a reference to the
OpenSearch 1.1 spec.  The rel="search" link relation is
registered for about a year.  Oh yes, there is this tiny
bit of "happiana" and RFC 4288 standards tree, but "let's
see what happens" (before giving up on this registration).

> - a google-group as the contact is really volatile.

Well, it's how the OpenSearch community works, they have a
MediaWiki installation with talk pages, and a mailing list
hosted by Google groups.  For at least five years, I can't
tell how it was when this work was still hosted by A9.com.
AFAIK Amazon still donates the domain, and they certainly
donated the OpenSearch XML name space URI some years ago.

> Is there no way to put a legally registered entity
> instead? I think even a9.com would be better.

I'm trying to register a well-known media type used in all major
browsers and on many web pages, but I cannot claim
that I try this on behalf of A9.

The OpenSearch.org folks know that I want this media type
to be registered since I-D.ellermann-opensearch-00 (2008),
and so far nobody had objections.  Sadly there were no
volunteers to create an RFC, and the proposal to create a
DTD for a future RFC died in a resounding silence.

> - Similarly http://www.opensearch.org/ is rather a
> volatile change controller.

This actually is the "change controller" for some years,
but IANAL and certainly not speaking for A9.

-Frank

<URL:http://www.opensearch.org/User:Xyzzy>
<URL:http://www.opensearch.org/Specifications/License>

From: Paul Libbrecht <[email-masked]>
Date: Tue, 25 Oct 2011 08:54:44 +0200
To: Frank Ellermann <[email-masked]>
Cc: IANA MIME types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/opensearchdescription+xml

Frank,

My comments are that of a dilletante in the field.=20
I hope someone will review the formal aspects of the procedure.

This is an interesting registration and it seems to be in good shape.

My usual suggestion is: what about clipboards?=20
OpenSearch Description Documents sound to be a natural candidate to be =
exchanged in clipboards (be copied-and-pasted, be drag-and-dropped, =
...). Do I mistake?
Hence I would like to suggest you add two lines in the additional =
information section such as the following:
- Windows Clipboard Flavor Name: "OpenSearch Description Document"
- Macintosh Uniform Type Identifier: org.opensearch.description conforms =
to public.xml

My guts feelings about the "responsibility" part of the registration is =
that it lacks a tiny bit of formality:
- isn't the WhatWG HTML a "place" for drafting a format that will =
hopefully end up be a W3C standard? I would prefer a W3C document to be =
referred to.
- a google-group as the contact is really volatile. Is there no way to =
put a legally registered entity instead? I think even a9.com would be =
better.=20
- Similarly http://www.opensearch.org/ is rather a volatile change =
controller. Provided a domain is more or less what its whois entry is, =
it means A9.com is the controller (the registered company in the US). =
Rather say that.

paul

Le 20 oct. 2011 =E0 13:03, Frank Ellermann a =E9crit :

>   Type name:      application
>=20
>   Subtype name:   opensearchdescription+xml
>=20
>   Required parameters:
>                   There are no required parameters.
>=20
>   Optional parameters:
>                   charset (defaults to "UTF-8")
>=20
>   Encoding considerations:
>                   Identical to those of "application/xml" as described
>                   in RFC 3023; especially "UTF-8" (RFC 3629) and its
>                   proper subset "US-ASCII" are supposed to work.
>                   For non-ASCII documents served as "text/xml" the
>                   "charset" parameter is required; this might be
>                   relevant when authors are unable to configure the
>                   server hosting their OSDD (OpenSearch Description
>                   Document).
>=20
>   Security considerations:
>                   All general security and privacy considerations for
>                   sending queries to servers specified in an URL are
>                   applicable.
>=20
>                   Where clients support the optional update feature in
>                   OSDDs it affects the privacy of users.
>=20
>                   The Ecmascript API AddSearchProvider() typically
>                   enforces a "same origin" policy for the OSDD; the =
URL
>                   element within the OSDD can designate a third party
>                   as search provider.
>=20
>                   An OSDD can claim to be a search description for X,
>                   but actually do something else.
>=20
>   Interoperability considerations:
>                   OSDDs use the <http://a9.com/-/spec/opensearch/1.1/>
>                   XML name space, optionally in conjunction with other
>                   XML name spaces for extensions or application =
specific
>                   purposes.
>=20
>   Published specification:
>                   =
<http://www.opensearch.org/Specifications/OpenSearch/1.1>
>=20
>   Applications that use this media type:
>                   Various Web browsers, search engines, and software
>                   libraries support OSDDs.  The "search" link relation
>                   is used on many Web pages with this media type.
>=20
>                   The Ecmascript API AddSearchProvider() documented =
for
>                   WhatWG HTML uses this media type.
>=20
>   Additional information:
>                   OSDDs have no "magic numbers" as defined in RFC =
4288.
>                   There are no special "common file name extensions" =
for
>                   OSDDs, OSDDs are XML documents.  If specific =
extensions
>                   are desired ".a9.xml" (or similar) might do the =
trick.
>=20
>   Person & email address to contact for further information:
>                   <http://groups.google.com/group/opensearch>
>                   <http://www.opensearch.org/Community/Guidelines>
>=20
>   Intended usage: COMMON
>=20
>   Restrictions on usage:
>                   None
>=20
>   Author:         DeWitt Clinton
>=20
>   Change controller:
>                   <http://www.opensearch.org/>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Sender: [email-masked]
Date: Mon, 24 Oct 2011 21:01:51 -0400
From: mike amundsen <[email-masked]>
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review: application/json-patch

responses inline....

On Mon, Oct 24, 2011 at 19:34, Paul C. Bryan <[email-masked]> wrote:
> Hi Mike:
>
> Thanks for the review and comments. My responses, inline...
>
> On Mon, 2011-10-24 at 19:19 -0400, mike amundsen wrote:
>> Paul:
>>
>> checking the I-D document itself:
>>
>> Sec #4 Operations:
>> "It is an error condition if an operation object contains more than
>> one operation member."
>>
>> I am not clear on what this is telling me:
>> - the same JSON Pointer expression cannot appear more than once in a document
>> - something else?
>
> What I'm trying to say (evidently not very well yet!) is that you can't
> have a operation object with "add" and "remove" at the same time. Only
> one operation member per operation object.

ok, so this is probably just a "vocabulary" detail. "operation",
"operation object", "operation member" maybe a glossary or just some
simple oneline definitions up front can help clear that up.

>
>> possibly consider adding an example of a document that should be
>> rejected as it is malformed.
>
> Will do, thanks.
cool.

>
>> Sec #5 Error Handling
>> "In the event of an error condition, evaluation of the JSON Patch
>> document terminates and modification of the target document fails to
>> complete."
>>
>> Does this mean the server should treat the document as an
>> "all-or-nothing" case? when an error occurs is the document left in a
>> "partial state" or left at the "initial state" before the request? is
>> this something you want to detail in the spec? if yes, you might want
>> to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) .
>
> HTTP PATCH is clear on the semantics, namely, "If the entire patch
> document cannot be successfully applied, then the server MUST NOT apply
> any of the changes." I've left this out of my spec, but I think there's
> no good reason not to be clearer by saying application of a sequence of
> patches SHOULD be atomic. Implementations are free to be even stricter
> with a MUST of their own, as HTTP PATCH is. Thoughts?

yep, the PATCH semantics are clear on that and it's a good idea to
stick with them. I'd proly reference those semantics in the I-D then.
either in the error handling section or possibly in another area of
the I-D.

>
>> It looks like your operations account for an error condition at the
>> individual "node" level:
>> "It is an error condition if the value to be replaced does not exist.", etc.
>
> Indeed.
>
>> Are there error conditions that might occur at the "document" level
>> (or some other node above the target?
>>
>> You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes
>> to common error conditions in processing the patch); is this something
>> you want to include here or leave that up to the server to decide?
>
> Since JSON Patch is not specific to HTTP, I'm content to defer to HTTP
> PATCH and HTTP specifications, which amply document how to handle
> situations such as when one attempts to apply an HTTP PATCH against a
> resource that does not exist.

ok, i can see that. however, you've outline some error conditions in
your document. do you have any plans to indicate servers
[MUST|SHOULD|MAY] return the details of the errors encountered
("member to be added in the object already exists", "the specified
index is greater than the number of elements in the existing array",
etc.) and if yes, any suggestions on what the response would look
like? I'm not sure this is needed (maybe you want to leave all that to
implementors), but wanted to ask about it here.

Mike

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

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Oct 2011 16:34:41 -0700
Subject: Re: [ietf-types] Request for review: application/json-patch

Hi Mike:

Thanks for the review and comments. My responses, inline...

On Mon, 2011-10-24 at 19:19 -0400, mike amundsen wrote:
> Paul:
> 
> checking the I-D document itself:
> 
> Sec #4 Operations:
> "It is an error condition if an operation object contains more than
> one operation member."
> 
> I am not clear on what this is telling me:
> - the same JSON Pointer expression cannot appear more than once in a document
> - something else?

What I'm trying to say (evidently not very well yet!) is that you can't
have a operation object with "add" and "remove" at the same time. Only
one operation member per operation object.

> possibly consider adding an example of a document that should be
> rejected as it is malformed.

Will do, thanks.

> Sec #5 Error Handling
> "In the event of an error condition, evaluation of the JSON Patch
> document terminates and modification of the target document fails to
> complete."
> 
> Does this mean the server should treat the document as an
> "all-or-nothing" case? when an error occurs is the document left in a
> "partial state" or left at the "initial state" before the request? is
> this something you want to detail in the spec? if yes, you might want
> to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) .

HTTP PATCH is clear on the semantics, namely, "If the entire patch
document cannot be successfully applied, then the server MUST NOT apply
any of the changes." I've left this out of my spec, but I think there's
no good reason not to be clearer by saying application of a sequence of
patches SHOULD be atomic. Implementations are free to be even stricter
with a MUST of their own, as HTTP PATCH is. Thoughts?

> It looks like your operations account for an error condition at the
> individual "node" level:
> "It is an error condition if the value to be replaced does not exist.", etc.

Indeed.

> Are there error conditions that might occur at the "document" level
> (or some other node above the target?
> 
> You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes
> to common error conditions in processing the patch); is this something
> you want to include here or leave that up to the server to decide?

Since JSON Patch is not specific to HTTP, I'm content to defer to HTTP
PATCH and HTTP specifications, which amply document how to handle
situations such as when one attempts to apply an HTTP PATCH against a
resource that does not exist.

Thanks again!

Paul

Sender: [email-masked]
Date: Mon, 24 Oct 2011 19:19:08 -0400
From: mike amundsen <[email-masked]>
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review: application/json-patch

Paul:

checking the I-D document itself:

Sec #4 Operations:
"It is an error condition if an operation object contains more than
one operation member."

I am not clear on what this is telling me:
- the same JSON Pointer expression cannot appear more than once in a docume=
nt
- something else?

possibly consider adding an example of a document that should be
rejected as it is malformed.

Sec #5 Error Handling
"In the event of an error condition, evaluation of the JSON Patch
document terminates and modification of the target document fails to
complete."

Does this mean the server should treat the document as an
"all-or-nothing" case? when an error occurs is the document left in a
"partial state" or left at the "initial state" before the request? is
this something you want to detail in the spec? if yes, you might want
to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) .

It looks like your operations account for an error condition at the
individual "node" level:
"It is an error condition if the value to be replaced does not exist.", etc=
.

Are there error conditions that might occur at the "document" level
(or some other node above the target?

You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes
to common error conditions in processing the patch); is this something
you want to include here or leave that up to the server to decide?

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Mon, Oct 24, 2011 at 17:02, Paul C. Bryan <[email-masked]> wro=
te:
> I'm preparing for possibly taking an informational Internet-Draft [1]
> toward a proposed standard. I'm requesting review and feedback on the
> "application/json-patch" media type. To wit:
>
> -----
>
> The Internet media type for a JSON Patch document is application/
> json-patch.
>
> Type name: =A0application
>
> Subtype name: =A0json-patch
>
> Required parameters: =A0none
>
> Optional parameters: =A0 none
>
> Encoding considerations:
> =A0 Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32.
>
> Security considerations:
> =A0 See Security Considerations in section 8.
>
> Interoperability considerations: =A0N/A
>
> Published specification:
> =A0 draft-pbryan-json-patch-02
>
> Applications that use this media type:
> =A0 HTTP clients and servers.
>
> Additional information:
>
> =A0 Magic number(s): =A0N/A
>
> =A0 File extension(s): =A0.json-patch
>
> =A0 Macintosh file type code(s): =A0TEXT
>
> Person & email address to contact for further information:
> =A0 Paul C. Bryan <[email-masked]>
>
> Intended usage: =A0COMMON
>
> Restrictions on usage: =A0none
>
> Author: =A0Paul C. Bryan <[email-masked]>
>
> Change controller: =A0Paul C. Bryan <[email-masked]>
>
> -----
>
> Thank you for your consideration.
>
> Paul C. Bryan
> [email-masked]
>
> [1] http://www.ietf.org/id/draft-pbryan-json-patch-02.txt
>
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
>

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Oct 2011 14:29:55 -0700
Subject: Re: [ietf-types] Request for review: application/json-patch

On Mon, 2011-10-24 at 14:24 -0700, Paul C. Bryan wrote:
> application/schema
And application/patch, even.

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Oct 2011 14:24:21 -0700
Subject: Re: [ietf-types] Request for review: application/json-patch

On Mon, 2011-10-24 at 23:11 +0200, Bjoern Hoehrmann wrote:
> * Paul C. Bryan wrote:
> >The Internet media type for a JSON Patch document is application/
> >json-patch.
> 
> What is your reasoning behind not using the "+json" convention?

In a previous draft, it was "application/patch+json", but I was advised
that:

a) application/schema was possibly too basic a base type, and
b) there is no formalization around +json extension yet.

> >Type name:  application
> >
> >Subtype name:  json-patch
> >
> >Required parameters:  none
> >
> >Optional parameters:   none
> >
> >Encoding considerations:
> >   Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32.
> 
> Either say something like "Same as for application/json." or "binary".
> It would seem to me that RFC 4627 is mistaken in using "8bit" as that
> is "The content of the media type consists solely of CRLF-delimited
> 8bit text." but JSON does not require CRLF.

Okay, thanks.

> >Applications that use this media type:
> >   HTTP clients and servers.
> 
> Well. Revision control systems for instance might use it.

True. Is there a way to just indicate general purpose usage instead of
trying to enumerate all the specific types of applications I could
imagine making use of this?

> >Change controller:  Paul C. Bryan <[email-masked]>
> 
> This would have to be some standards organization like "The IETF."

Okay.

Thanks for the review.

Paul

From: Bjoern Hoehrmann <[email-masked]>
To: "Paul C. Bryan" <[email-masked]>
Date: Mon, 24 Oct 2011 23:11:59 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review: application/json-patch

* Paul C. Bryan wrote:
>The Internet media type for a JSON Patch document is application/
>json-patch.

What is your reasoning behind not using the "+json" convention?

>Type name:  application
>
>Subtype name:  json-patch
>
>Required parameters:  none
>
>Optional parameters:   none
>
>Encoding considerations:
>   Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32.

Either say something like "Same as for application/json." or "binary".
It would seem to me that RFC 4627 is mistaken in using "8bit" as that
is "The content of the media type consists solely of CRLF-delimited
8bit text." but JSON does not require CRLF.

>Applications that use this media type:
>   HTTP clients and servers.

Well. Revision control systems for instance might use it.

>Change controller:  Paul C. Bryan <[email-masked]>

This would have to be some standards organization like "The IETF."
-- 
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: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Oct 2011 14:02:23 -0700
Subject: [ietf-types] Request for review: application/json-patch

I'm preparing for possibly taking an informational Internet-Draft [1]
toward a proposed standard. I'm requesting review and feedback on the
"application/json-patch" media type. To wit:

-----

The Internet media type for a JSON Patch document is application/
json-patch.

Type name:  application

Subtype name:  json-patch

Required parameters:  none

Optional parameters:   none

Encoding considerations:
   Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32.

Security considerations:
   See Security Considerations in section 8.

Interoperability considerations:  N/A

Published specification:
   draft-pbryan-json-patch-02

Applications that use this media type:
   HTTP clients and servers.

Additional information:

   Magic number(s):  N/A

   File extension(s):  .json-patch

   Macintosh file type code(s):  TEXT

Person & email address to contact for further information:
   Paul C. Bryan <[email-masked]>

Intended usage:  COMMON

Restrictions on usage:  none

Author:  Paul C. Bryan <[email-masked]>

Change controller:  Paul C. Bryan <[email-masked]>

-----

Thank you for your consideration.

Paul C. Bryan
[email-masked]

[1] http://www.ietf.org/id/draft-pbryan-json-patch-02.txt

From: Frank Ellermann <[email-masked]>
Date: Thu, 20 Oct 2011 13:03:38 +0200
To: IANA MIME types <[email-masked]>
Subject: [ietf-types] Registration of media type application/opensearchdescription+xml

   Type name:      application

   Subtype name:   opensearchdescription+xml

   Required parameters:
                   There are no required parameters.

   Optional parameters:
                   charset (defaults to "UTF-8")

   Encoding considerations:
                   Identical to those of "application/xml" as described
                   in RFC 3023; especially "UTF-8" (RFC 3629) and its
                   proper subset "US-ASCII" are supposed to work.
                   For non-ASCII documents served as "text/xml" the
                   "charset" parameter is required; this might be
                   relevant when authors are unable to configure the
                   server hosting their OSDD (OpenSearch Description
                   Document).

   Security considerations:
                   All general security and privacy considerations for
                   sending queries to servers specified in an URL are
                   applicable.

                   Where clients support the optional update feature in
                   OSDDs it affects the privacy of users.

                   The Ecmascript API AddSearchProvider() typically
                   enforces a "same origin" policy for the OSDD; the URL
                   element within the OSDD can designate a third party
                   as search provider.

                   An OSDD can claim to be a search description for X,
                   but actually do something else.

   Interoperability considerations:
                   OSDDs use the <http://a9.com/-/spec/opensearch/1.1/>
                   XML name space, optionally in conjunction with other
                   XML name spaces for extensions or application specific
                   purposes.

   Published specification:
                   <http://www.opensearch.org/Specifications/OpenSearch/1.1>

   Applications that use this media type:
                   Various Web browsers, search engines, and software
                   libraries support OSDDs.  The "search" link relation
                   is used on many Web pages with this media type.

                   The Ecmascript API AddSearchProvider() documented for
                   WhatWG HTML uses this media type.

   Additional information:
                   OSDDs have no "magic numbers" as defined in RFC 4288.
                   There are no special "common file name extensions" for
                   OSDDs, OSDDs are XML documents.  If specific extensions
                   are desired ".a9.xml" (or similar) might do the trick.

   Person & email address to contact for further information:
                   <http://groups.google.com/group/opensearch>
                   <http://www.opensearch.org/Community/Guidelines>

   Intended usage: COMMON

   Restrictions on usage:
                   None

   Author:         DeWitt Clinton

   Change controller:
                   <http://www.opensearch.org/>

From: "Michael Steidl \(IPTC\)" <[email-masked]>
To: <[email-masked]>
Date: Fri, 7 Oct 2011 21:40:39 +0200
Organization: IPTC
Subject: Re: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml

Hi Jan

The IPTC has already registered 4 MIME Types for our suite of news =
exchange formats (vnd.iptc.g2.conceptitem+xml, =
vnd.iptc.g2.knowledgeitem+xml, vnd.iptc.g2.newsitem+xml, =
vnd.iptc.g2.packageitem+xml), all without a specific file extension. The =
main reason is that such XML instances are usually not delivered by =
access to a file but by a API to a RESTful web service. So why should we =
start defining specific extension for additional MIME types with no =
urgent practical need for it.

Michael

> -----Original Message-----
> From: Jan Algermissen [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 4:58 PM
> To: Michael Steidl (IPTC)
> Cc: [email-masked]
> Subject: Re: [ietf-types] Updated registration of media type
> application/vnd.iptc.g2.newsmessage+xml
>=20
> Hi,
>=20
> as per Mark Baker's comment, I'd suggest, too to use a specific file
> extension, such as newsml
>=20
> Jan
>=20
>=20
> On Oct 4, 2011, at 10:37 AM, Michael Steidl (IPTC) wrote:
>=20
> > Updated after responses to first draft in mid September.
> >
> > To:
> > [email-masked]
> >
> > Subject:
> > Registration of media type application/vnd.iptc.g2.newsmessage+xml
> >
> > Media Type Name: application
> >
> > Subtype name: vnd.iptc.g2.newsmessage+xml
> >
> > Required parameters: none
> >
> > Optional parameters: charset
> > Same as charset parameter of application/xml as specified in
> > RFC 3023 [RFC3023]
> >
> > Encoding considerations:Same as encoding considerations
> > of application/xml as specified in RFC 3023, section 3.2
> >
> > 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.
> >
> > Interoperability considerations:
> >
> > Published specification:
> >
> > NewsML-G2 version 2.9 specifications and implementation guidelines
> >
> > http://www.iptc.org/std/NewsML-G2/
> >
> > Applications which use this media type: content management systems,
> news exchange systems
> >
> > Additional information:
> >
> > Magic number(s): none
> >
> > File extension(s): .xml
> >
> > Macintosh File Type Code(s): Identical to those of
> > "application/xml" as described in RFC3023, "TEXT"
> >
> > Windows Clipboard Flavor Name: "IPTC NewsMessage XML"
> >
> > Macintosh Uniform Type Identifier: org.iptc.newsmessage conforms to
> public.xml
> >
> > 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].
> >
> > Intended usage:
> >
> > A News Message is a wrapper of one or more IPTC G2 items for
> > distribution and transmission purposes. It provides transmission-
> specific
> > properties in a header which is shared by all included IPTC G2 =
items.
> >
> > Other Information/General Comment: none
> >
> > Person to contact for further information:
> > Michael Steidl <[email-masked]>
> >
> > Author/Change controller:
> > Michael Steidl <[email-masked]>
> >
> >
> >
> >
> > Michael Steidl
> > Managing Director of the IPTC [[email-masked]]
> > International Press Telecommunications Council
> > Web: www.iptc.org - on Twitter @IPTC
> > Business office address:
> > 20 Garrick Street, London WC2E 9BT, United Kingdom
> > Registered in England, company no 101096
> >
> > _______________________________________________
> > ietf-types mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-types

From: Jan Algermissen <[email-masked]>
Date: Tue, 4 Oct 2011 16:57:44 +0200
To: Michael Steidl (IPTC) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml

Hi,

as per Mark Baker's comment, I'd suggest, too to use a specific file =
extension, such as newsml

Jan

On Oct 4, 2011, at 10:37 AM, Michael Steidl (IPTC) wrote:

> Updated after responses to first draft in mid September.
> =20
> To:
> [email-masked]
> =20
> Subject:
> Registration of media type application/vnd.iptc.g2.newsmessage+xml
> =20
> Media Type Name: application
> =20
> Subtype name: vnd.iptc.g2.newsmessage+xml
> =20
> Required parameters: none
> =20
> Optional parameters: charset
> Same as charset parameter of application/xml as specified in
> RFC 3023 [RFC3023]
> =20
> Encoding considerations:Same as encoding considerations
> of application/xml as specified 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
> NewsML-G2 version 2.9 specifications and implementation guidelines
> =20
> http://www.iptc.org/std/NewsML-G2/
> =20
> Applications which use this media type: content management systems, =
news exchange systems
> =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 NewsMessage XML"
> =20
> Macintosh Uniform Type Identifier: org.iptc.newsmessage 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 News Message is a wrapper of one or more IPTC G2 items for
> distribution and transmission purposes. It provides =
transmission-specific
> properties in a header which is shared by all included IPTC G2 items.
> =20
> Other Information/General Comment: none
> =20
> Person to contact for further information:
> Michael Steidl <[email-masked]>
> =20
> Author/Change controller:
> Michael Steidl <[email-masked]>
> =20
> =20
> =20
> =20
> Michael Steidl
> Managing Director of the IPTC [[email-masked]]
> International Press Telecommunications Council=20
> Web: www.iptc.org - on Twitter @IPTC
> Business office address:
> 20 Garrick Street, London WC2E 9BT, United Kingdom
> Registered in England, company no 101096
> =20
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: "Michael Steidl \(IPTC\)" <[email-masked]>
To: <[email-masked]>
Date: Tue, 4 Oct 2011 10:37:40 +0200
Organization: IPTC
Subject: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml

This is a multi-part message in MIME format.

------=_NextPart_000_0027_01CC8281.A41C4550
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Updated after responses to first draft in mid September.

=20

To:

[email-masked]=20

=20

Subject:

Registration of media type application/vnd.iptc.g2.newsmessage+xml

=20

Media Type Name: application

=20

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

=20

Required parameters: none

=20

Optional parameters: charset

Same as charset parameter of application/xml as specified in=20

RFC 3023 [RFC3023]

=20

Encoding considerations:Same as encoding considerations

of application/xml as specified 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

NewsML-G2 version 2.9 specifications and implementation guidelines

=20

http://www.iptc.org/std/NewsML-G2/

=20

Applications which use this media type: content management systems, news =
exchange systems

=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 NewsMessage XML"

=20

Macintosh Uniform Type Identifier: org.iptc.newsmessage 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 News Message is a wrapper of one or more IPTC G2 items for=20

distribution and transmission purposes. It provides =
transmission-specific=20

properties in a header which is shared by all included IPTC G2 items.

=20

Other Information/General Comment: none

=20

Person to contact for further information:

Michael Steidl <[email-masked]>

=20

Author/Change controller:

Michael Steidl <[email-masked]>

=20

=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_0027_01CC8281.A41C4550
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
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=
pdated after responses to first draft in mid =
September.<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=
o:<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=
[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: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=
ubject:<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'>R=
egistration of media type =
application/vnd.iptc.g2.newsmessage+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=
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.newsmessage+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'>S=
ame as charset parameter of application/xml as specified in =
<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'>R=
FC 3023 [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'><=
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:Same as encoding =
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=
f application/xml as specified 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'>N=
ewsML-G2 version 2.9 specifications and implementation =
guidelines<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/NewsML-G2/<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: content management systems, news =
exchange systems<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 =
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 =
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 NewsMessage =
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.newsmessage 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=
 News Message is a wrapper of one or more IPTC G2 items for =
<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=
istribution and transmission purposes. It provides transmission-specific =
<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'>p=
roperties in a header which is shared by all included IPTC G2 =
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'>M=
ichael Steidl &lt;[email-masked]&gt;<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'>M=
ichael Steidl &lt;[email-masked]&gt;<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:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-GB><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-GB><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><b><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'=
> - on Twitter </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_0027_01CC8281.A41C4550--