Subject: [ietf-types] request for review: text/mizar
From: Jesse Alama <[email-masked]>
To: [email-masked]
Date: Sun, 22 Jan 2012 13:16:30 +0000
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

(Reposted to [email-masked] rather than [email-masked],
to which it was [wrongly] initially submitted, and thus my have
hampered discussion about the proposed MIME type.

What follows is the result of completing the form at
http://www.iana.org/cgi-bin/mediatypes.pl .)
======================================================================
Name : Jesse Alama

Email : j.alama at fct.unl.pt

MIME media type name : text

MIME subtype name : Standards Tree -mizar

Required parameters : none

Optional parameters :
none

Encoding considerations : 7bit

Security considerations :
none

Interoperability considerations :

Published specification :
A. Grabowski, A. Kornilowicz, and A. Naumowicz, "Mizar in a Nutshell",
Journal of Formalized Reasoning 3(2), 2010, pp. 153--245.

Applications which use this media :
The mizar suite of tools

Additional information :

1. Magic number(s) : none
2. File extension(s) : .miz
3. Macintosh file type code : none
4. Object Identifiers: none

Window clipboard flavor: "Mizar"
Macintosh Uniform Type Identifier: "org.mizar" conforms to "public.text"

The mizar language is a language for formalized mathematical documents.
Authors use this language to express definitions of mathematical
concepts, and express and proof formal mathematical statements. The
language has been developed since the 1970s and today is used in
teaching logic and mathematics in various high school and university
settings. The library of mathematical knowledge formalized in the mizar
language, the Mizar Mathematical Library, consists (at the time of
application) of more than 1100 "articles" which, like an ordinary
mathematical article in a journal, are coherent presentations and
developments of mathematics.

Person to contact for further information :

1. Name : Jesse Alama
2. Email : j.alama at fct.unl.pt

Intended usage : Common
This media type is intended to be used by text editors and affiliated
programs that read text (e.g., web browsers).

Author/Change controller : Adam Naumowicz
Association of Mizar Users
sum at mizar.uwb.edu.pl

-- 
Jesse Alama
http://centria.di.fct.unl.pt/~alama/

From: Bjoern Hoehrmann <[email-masked]>
To: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sat, 21 Jan 2012 00:41:52 +0100
Cc: Lorenzo Miniero <[email-masked]>, Chris Boulton <[email-masked]>, Eric Burger <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Registration of application/mrb-publish+xml and application/mrb-consumer+xml

* Worley, Dale R (Dale) wrote:
>We will work on updating the I-D based on your comments.  But there is
>a difficulty with this item:  "Media Resource Broker" is the term used
>by the various vendors of MRB devices.  And this I-D is one of a very
>few IETF documents that describes MRB functionality.  Unfortunately,
>there is no larger, better-known class that contains MRB.
>
>Perhaps we could at least warn the reader that the RFC is the only
>generic description of MRB:
>
>   Applications which use this media type:   This document type has been
>      used to support a Media Resource Broker (MRB) entity.  MRB is
>      described in RFCXXXX. [[NOTE TO RFC-EDITOR/IANA: Please replace
>      XXXX with the RFC number of this specification.]]

Regard the comment as an editorial nit that does not really have to be
addressed. My problem is that I do not know "Media Resource Broker" in
the way I know "video conferencing system", "photo editor", or "real-
time chat application". Something about the problem it solves (random
example, "Informs SIP applications of available communication options")
or the enviroment it is used in (random example, "real-time telephony
applications") would be nice, but if there is any trouble coming up with
text for that, don't bother trying as far as I am concerned.
-- 
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: "Worley, Dale R (Dale)" <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Jan 2012 18:24:48 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: Lorenzo Miniero <[email-masked]>, Chris Boulton <[email-masked]>, Eric Burger <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Registration of application/mrb-publish+xml and application/mrb-consumer+xml

> From: Bjoern Hoehrmann [[email-masked]]
>=20
> >   Published specification:   Section 10 of RFCXXXX [[NOTE TO RFC-
> >      EDITOR/IANA: Please replace XXXX with the RFC number of this
> >      specification.]].
> >
> >   Applications which use this media type:   This document type has been
> >      used to support a Media Resource Broker (MRB) entity.
>=20
> I suppose this might be okay in the context of the document, in general
> it should give people like "oh, this is for document management" or "oh,
> yet enother 3d modeling format".

We will work on updating the I-D based on your comments.  But there is
a difficulty with this item:  "Media Resource Broker" is the term used
by the various vendors of MRB devices.  And this I-D is one of a very
few IETF documents that describes MRB functionality.  Unfortunately,
there is no larger, better-known class that contains MRB.

Perhaps we could at least warn the reader that the RFC is the only
generic description of MRB:

   Applications which use this media type:   This document type has been
      used to support a Media Resource Broker (MRB) entity.  MRB is
      described in RFCXXXX. [[NOTE TO RFC-EDITOR/IANA: Please replace
      XXXX with the RFC number of this specification.]]

Dale

From: Bjoern Hoehrmann <[email-masked]>
To: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 20 Jan 2012 18:09:29 +0100
Cc: Lorenzo Miniero <[email-masked]>, Chris Boulton <[email-masked]>, Eric Burger <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Registration of application/mrb-publish+xml and application/mrb-consumer+xml

* Worley, Dale R (Dale) wrote:
>13.2.  application/mrb-publish+xml MIME Type
>
>   MIME media type name:   application
>
>   MIME subtype name:   mrb-publish+xml

This is using an outdated template, the current one in RFC 4288 changes
the names of some fields and organizes some other fields differently.

>   Mandatory parameters:   none
>
>   Optional parameters:   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 [RFC3023].
>
>   Security considerations:   See Section 10 of RFC 3023 [RFC3023] and
>      Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
>      XXXX with the RFC number of this specification.]].
>
>   Interoperability considerations:   none.
>
>   Published specification:   Section 10 of RFCXXXX [[NOTE TO RFC-
>      EDITOR/IANA: Please replace XXXX with the RFC number of this
>      specification.]].
>
>   Applications which use this media type:   This document type has been
>      used to support a Media Resource Broker (MRB) entity.

I suppose this might be okay in the context of the document, in general
it should give people like "oh, this is for document management" or "oh,
yet enother 3d modeling format".

>   Additional Information:
>
>   Magic Number:   None
>
>   File Extension:   .xdf

I note that you propose the same file name extension for both types. Do
make sure that's not a copy and paste error.

>   Macintosh file type code:   "TEXT"
>
>   Personal and email address for further information:   Chris Boulton,
>      [email-masked]

The typical rendering is `Chris Boulton <[email-masked]>`.

>13.3.  application/mrb-consumer+xml MIME Type

(Same comments as above).
-- 
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: "Markus Lanthaler" <[email-masked]>
To: <[email-masked]>
Date: Fri, 20 Jan 2012 14:09:32 +0800
Subject: [ietf-types] Best practice for new MIME type: application/frame-ld+json

Hello,

We are currently working on an effort to standardize a way to describe
linked data in JSON. Consequently we plan to register a media type
application/ld+json (ld stands for linked data). We now came across the need
for another media type to label framing documents, i.e., again a JSON
document but with a completely different structure than a JSON-LD document.
The media type we came up with so far was application/frame-ld+json but some
people argued that we should follow this "+" pattern and call it
application/frame+ld+json instead.

>From talking with people from the HTTP WG this seems to be discouraged ([1],
[2]). Bjoern Hoehrmann suggested to go with application/ld-frame+json as
that "would be more in keeping with the terminology" and suggested to take
the discussion over to this mailing list. I would love to hear you opinion
on this.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0088.html
[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0089.html

Thanks,
Markus

From: "Worley, Dale R (Dale)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 19 Jan 2012 16:32:04 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: Lorenzo Miniero <[email-masked]>, Chris Boulton <[email-masked]>, Eric Burger <[email-masked]>
Subject: [ietf-types] Registration of application/mrb-publish+xml and application/mrb-consumer+xml

draft-ietf-mediactrl-mrb-12 will shortly be undergoing WGLC in the
MEDIACTRL WG.  In it, there are two new type registrations.  The
registrations are in sections 13.1 and 13.2 of
http://tools.ietf.org/id/draft-ietf-mediactrl-mrb-12.txt, which are
also copied below.

Your comments are appreciated.

Thanks,

Dale Worley (MEDIACTRL WG co-chair)
----------------------------------------------------------------------
13.2.  application/mrb-publish+xml MIME Type

   MIME media type name:   application

   MIME subtype name:   mrb-publish+xml

   Mandatory parameters:   none

   Optional parameters:   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 [RFC3023].

   Security considerations:   See Section 10 of RFC 3023 [RFC3023] and
      Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
      XXXX with the RFC number of this specification.]].

   Interoperability considerations:   none.

   Published specification:   Section 10 of RFCXXXX [[NOTE TO RFC-
      EDITOR/IANA: Please replace XXXX with the RFC number of this
      specification.]].

   Applications which use this media type:   This document type has been
      used to support a Media Resource Broker (MRB) entity.

   Additional Information:

   Magic Number:   None

   File Extension:   .xdf

   Macintosh file type code:   "TEXT"

   Personal and email address for further information:   Chris Boulton,
      [email-masked]

   Intended usage: COMMON

   Author/Change controller:   The IETF.

13.3.  application/mrb-consumer+xml MIME Type

   MIME media type name:   application

   MIME subtype name:   mrb-consumer+xml

   Mandatory parameters:   none

   Optional parameters:   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 [RFC3023].

   Security considerations:   See Section 10 of RFC 3023 [RFC3023] and
      Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
      XXXX with the RFC number of this specification.]].

   Interoperability considerations:   none.

   Published specification:   Section 11 of RFCXXXX [[NOTE TO RFC-
      EDITOR/IANA: Please replace XXXX with the RFC number of this
      specification.]].

   Applications which use this media type:   This document type has been
      used to support a Media Resource Broker (MRB) entity.

   Additional Information:

   Magic Number:   None

   File Extension:   .xdf

   Macintosh file type code:   "TEXT"

   Personal and email address for further information:   Chris Boulton,
      [email-masked]

   Intended usage: COMMON

   Author/Change controller:   The IETF.
----------------------------------------------------------------------
[END]

Date: Tue, 17 Jan 2012 11:19:11 -0500
From: Jeff Downs <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of application/smpte336m

The encoding considerations text of "binary and framed" in the proposed 
registration of application/smpte336m (as part of 
draft-ietf-payload-rtp-klv-02) comes literally out of the template in 
draft-ietf-payload-rtp-howto-01.

The format is, indeed, binary (not textual).  I reviewed RFC 3555 and 
the usage of "binary" vs. "framed" isn't very clear to me, but as I read 
it the difference is whether or not the payload data can exist 
"standalone" without the frame headers/transport data.  SMPTE 336M data 
can indeed exist outside such framing and be reasonably interpreted 
(without the notion of data timing), though this certainly does not fall 
within the scope of the I-D submitted by myself (rather it is the core 
of the SMPTE 336M specification itself).

I am more than happy to defer to the expertise of others; if dropping 
binary is the right thing to do here I am completely ok with that change.

Please include me directly on any follow-ups.

Jeff Downs
PAR Government Systems

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]]
Sent: Friday, January 13, 2012 10:46 AM
To: Ali C. Begen (abegen)
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-types] Registration of application/smpte336m

* Ali C. Begen (abegen) wrote:
>6.1.  Media Type Definition
>
>      Type name: application
>
>      Subtype name: smpte336m
>
>      Required parameters:
>
>         rate: RTP timestamp clock rate.  Typically chosen based on
>         sampling rate of metadata being transmitted, but other rates
>         can be specified.
>
>      Optional parameters: None
>
>      Encoding considerations: This media type is framed and binary; see
>      Section 4.8 of [RFC4288].

Why does this include "binary"?
-- 
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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 13 Jan 2012 16:46:02 +0100
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Registration of application/smpte336m

* Ali C. Begen (abegen) wrote:
>6.1.  Media Type Definition
>
>      Type name: application
>
>      Subtype name: smpte336m
>
>      Required parameters:
>
>         rate: RTP timestamp clock rate.  Typically chosen based on
>         sampling rate of metadata being transmitted, but other rates
>         can be specified.
>
>      Optional parameters: None
>
>      Encoding considerations: This media type is framed and binary; see
>      Section 4.8 of [RFC4288].

Why does this include "binary"?
-- 
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/ 

Content-class: urn:content-classes:message
Date: Wed, 11 Jan 2012 11:21:50 -0800
From: "Ali C. Begen (abegen)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [ietf-types] Registration of application/smpte336m

Hello,

draft-ietf-payload-rtp-klv-02 has finished WGLC in the PAYLOAD WG. There =
is one new registration in Section 6.1 of =
http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/?include_text=3D=
1=20

The relevant text is copied below as well.

Your comments are appreciated.

Thanks.=20
-acbegen (PAYLOAD WG Co-chair)

6.1.  Media Type Definition

      Type name: application

      Subtype name: smpte336m

      Required parameters:

         rate: RTP timestamp clock rate.  Typically chosen based on
         sampling rate of metadata being transmitted, but other rates
         can be specified.

      Optional parameters: None

      Encoding considerations: This media type is framed and binary; see
      Section 4.8 of [RFC4288].

      Security considerations: See Section 8 of RFCXXXX (note to RFC
      editor: please replace XXXX with the number assigned to this RFC).

      Interoperability considerations: Data items in smpte336m can be
      very diverse.  Receivers might only be capable of interpreting a
      subset of the possible data items; unrecognized items are skipped.
      Agreement on data items to be used out of band, via application
      profile or similar, is typical.

      Published specification: RFCXXXX

      Applications that use this media type: Streaming of metadata
      associated with simultaneously streamed video and transmission of
      [SMPTE336M] based media formats (e.g.  MXF [SMPTE377M]).

      Additional Information: none

      Person & email address to contact for further information: J.
      Downs <[email-masked]>; IETF Payload Working Group
      <[email-masked]>

      Intended usage: COMMON

      Restrictions on usage: This media type depends on RTP framing, and
      hence is only defined for transfer via RTP ([RFC3550]).  Transport
      within other framing protocols is not defined at this time.

      Author:

         J. Downs <[email-masked]>

         J. Arbeiter <[email-masked]>

      Change controller: IETF Payload working group delegated from the
      IESG.

Date: Wed, 11 Jan 2012 18:01:35 +0100
From: Julian Reschke <[email-masked]>
To: Jan Algermissen <[email-masked]>
Cc: [email-masked], Carl Reed <[email-masked]>
Subject: Re: [ietf-types] Request for review application/gml+xml

On 2012-01-11 17:50, Jan Algermissen wrote:
>
> On Jan 11, 2012, at 10:46 AM, Julian Reschke wrote:
>
>> On 2012-01-11 10:22, Jan Algermissen wrote:
>>>
>>> On Jan 11, 2012, at 9:38 AM, Julian Reschke wrote:
>>>
>>>> On 2012-01-11 08:05, Jan Algermissen wrote:
>>>>> Carl,
>>>>>
>>>>> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>>>>>
>>>>>> "version": If provided, this parameter indicates the GML version
>>>>>>     used in the GML document. Only the major and the first minor
>>>>>>     version number are provided, e.g. "3.2".
>>>>>>
>>>>>>     The value may be provided with or without quotes. i.e.,
>>>>>>     application/gml+xml; version=3.1 shall be treated as identical to
>>>>>>     application/gml+xml; version="3.1".
>>>>>>
>>>>>>     In cases where elements from multiple GML versions are used,
>>>>>>     the parameter shall indicate the highest GML version used in the
>>>>>>     document.
>>>>>>
>>>>>>     The parameter can be used to provide protocol-specific operations,
>>>>>>     such as version-based content negotiation in HTTP
>>>>>
>>>>> I cannot find the reference just now, but if I am not seriously wrong, media type parameters are not taken into account by HTTP conneg. (How could they, given that their meaning is defined by the media type itself except for q and charset et al.
>>>>> ...
>>>>
>>>> Why would that be a problem?
>>>
>>> I think that the correct way of implementing conneg is to strip all media type specific parameters before matching (otherwise the code would need to be aware of the media type specific parameters).
>>
>> But that's not what is specified in HTTP.
>
> Can you point me to that part of the spec? I saw the 'format' example in your reference to media type ranges, but I cannot (personally) read that the way you seem to do.
>
>>
>>> The proposed text above suggests that the version parameter would be recognized by such implementations - which it would not. I.e.
>>>
>>> Accept: application/gml+xml; version=3.1
>>>
>>> would maybe yield
>>>
>>> Content-Type: application/gml+xml; version=1.2
>>
>> I think that would be a bug according to the HTTP spec.
>
> Doh, I am shocked - if you are right then I have lived with a very clouded spot of HTTP in my brain for years.
>
> So you are saying, if there are parameters (besides q) that do not *exactly* match conneg should say 'Not Acceptable'?

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

> IOW, this would also not be correct:
>
> Accept: application/gml+xml; version=3.1
>
> Content-Type: application/gml+xml; version=3.5
>
> And also this would be incorrect:
>
> Accept: application/atom+xml;type=entry
>
> Content-Type: application/atom+xml
>
> Or am I misunderstanding you?

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

Best regards, Julian

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 17:50:48 +0100
To: Julian Reschke <[email-masked]>
Cc: [email-masked], Carl Reed <[email-masked]>
Subject: Re: [ietf-types] Request for review application/gml+xml

On Jan 11, 2012, at 10:46 AM, Julian Reschke wrote:

> On 2012-01-11 10:22, Jan Algermissen wrote:
>>=20
>> On Jan 11, 2012, at 9:38 AM, Julian Reschke wrote:
>>=20
>>> On 2012-01-11 08:05, Jan Algermissen wrote:
>>>> Carl,
>>>>=20
>>>> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>>>>=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
>>>>=20
>>>> I cannot find the reference just now, but if I am not seriously =
wrong, media type parameters are not taken into account by HTTP conneg. =
(How could they, given that their meaning is defined by the media type =
itself except for q and charset et al.
>>>> ...
>>>=20
>>> Why would that be a problem?
>>=20
>> I think that the correct way of implementing conneg is to strip all =
media type specific parameters before matching (otherwise the code would =
need to be aware of the media type specific parameters).
>=20
> But that's not what is specified in HTTP.

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

>=20
>> The proposed text above suggests that the version parameter would be =
recognized by such implementations - which it would not. I.e.
>>=20
>> Accept: application/gml+xml; version=3D3.1
>>=20
>> would maybe yield
>>=20
>> Content-Type: application/gml+xml; version=3D1.2
>=20
> I think that would be a bug according to the HTTP spec.

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

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

IOW, this would also not be correct:

Accept: application/gml+xml; version=3D3.1

Content-Type: application/gml+xml; version=3D3.5

And also this would be incorrect:

Accept: application/atom+xml;type=3Dentry

Content-Type: application/atom+xml

Or am I misunderstanding you?

Jan

>=20
>> ...
>=20
> Best regards, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jan 2012 13:35:28 +0100
Cc: ECRIT Org <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for review of Media Type 'application/lostsync+xml'

* Hannes Tschofenig wrote:
>thank you for your review. I have updated the draft based on your comments. 
>Here is the new draft: http://www.ietf.org/id/draft-ietf-ecrit-lost-sync-14.txt

RFC 3023 section 7.1 starts out:

   Registrations for new XML-based media types under top-level types
   other than "text" SHOULD, in specifying the charset parameter and
   encoding considerations, define them as: "Same as [charset parameter
   / encoding considerations] of application/xml as specified in RFC
   3023."

So, instead of "Indicates the character encoding of enclosed XML." you
should have "Same as the charset parameter of application/xml as ...";
same for the encoding considerations.
-- 
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, 11 Jan 2012 10:46:08 +0100
From: Julian Reschke <[email-masked]>
To: Jan Algermissen <[email-masked]>
Cc: [email-masked], Carl Reed <[email-masked]>
Subject: Re: [ietf-types] Request for review application/gml+xml

On 2012-01-11 10:22, Jan Algermissen wrote:
>
> On Jan 11, 2012, at 9:38 AM, Julian Reschke wrote:
>
>> On 2012-01-11 08:05, Jan Algermissen wrote:
>>> Carl,
>>>
>>> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>>>
>>>> "version": If provided, this parameter indicates the GML version
>>>>     used in the GML document. Only the major and the first minor
>>>>     version number are provided, e.g. "3.2".
>>>>
>>>>     The value may be provided with or without quotes. i.e.,
>>>>     application/gml+xml; version=3.1 shall be treated as identical to
>>>>     application/gml+xml; version="3.1".
>>>>
>>>>     In cases where elements from multiple GML versions are used,
>>>>     the parameter shall indicate the highest GML version used in the
>>>>     document.
>>>>
>>>>     The parameter can be used to provide protocol-specific operations,
>>>>     such as version-based content negotiation in HTTP
>>>
>>> I cannot find the reference just now, but if I am not seriously wrong, media type parameters are not taken into account by HTTP conneg. (How could they, given that their meaning is defined by the media type itself except for q and charset et al.
>>> ...
>>
>> Why would that be a problem?
>
> I think that the correct way of implementing conneg is to strip all media type specific parameters before matching (otherwise the code would need to be aware of the media type specific parameters).

But that's not what is specified in HTTP.

> The proposed text above suggests that the version parameter would be recognized by such implementations - which it would not. I.e.
>
> Accept: application/gml+xml; version=3.1
>
> would maybe yield
>
> Content-Type: application/gml+xml; version=1.2

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

> ...

Best regards, Julian

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jan 2012 11:30:04 +0200
To: Bjoern Hoehrmann <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, ECRIT Org <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for review of Media Type 'application/lostsync+xml'

Hi Bjoern,=20

thank you for your review. I have updated the draft based on your =
comments.=20
Here is the new draft: =
http://www.ietf.org/id/draft-ietf-ecrit-lost-sync-14.txt

Ciao
Hannes

On Sep 18, 2011, at 10:29 PM, Bjoern Hoehrmann wrote:

> * Hannes Tschofenig wrote:
>>  MIME media type name:  application
>>=20
>>=20
>>  MIME subtype name:  lostsync+xml
>=20
> This is based on an outdated version of the template, the current one =
is
> in RFC 4288; some of the fields are named and organized differently.
>=20
>>  Optional parameters:  charset
>>=20
>>     Indicates the character encoding of enclosed XML.
>>=20
>>=20
>>  Encoding considerations:  Uses XML, which can employ 8-bit
>>     characters, depending on the character encoding used.  See RFC
>>     3023 [RFC3023], Section 3.2.
>=20
> RFC 3023 should be referenced as specified in RFC 3023 section 7.1.
>=20
>>  Additional information:
>>=20
>>     Magic Number:  None
>>=20
>>=20
>>     File Extension:  .lostsyncxml
>>=20
>>=20
>>     Macintosh file type code:  'TEXT'
>>=20
>>=20
>>  Personal and email address for further information:  Hannes
>>     Tschofenig, [email-masked]
>=20
> (The rendering "Name <email>" is more often used for this.)
> --=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

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 10:22:48 +0100
To: Julian Reschke <[email-masked]>
Cc: [email-masked], Carl Reed <[email-masked]>
Subject: Re: [ietf-types] Request for review application/gml+xml

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

> On 2012-01-11 08:05, Jan Algermissen wrote:
>> Carl,
>>=20
>> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>>=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
>>=20
>> I cannot find the reference just now, but if I am not seriously =
wrong, media type parameters are not taken into account by HTTP conneg. =
(How could they, given that their meaning is defined by the media type =
itself except for q and charset et al.
>> ...
>=20
> Why would that be a problem?

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

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

Accept: application/gml+xml; version=3D3.1

would maybe yield

Content-Type: application/gml+xml; version=3D1.2

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

Sorry if I am confusing this somehow.

Jan

>=20
> See
>=20
> =
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#rf=
c.section.6.1.p.13>
>=20
> Best regards, Julian
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Wed, 11 Jan 2012 09:38:44 +0100
From: Julian Reschke <[email-masked]>
To: Jan Algermissen <[email-masked]>
Cc: [email-masked], Carl Reed <[email-masked]>
Subject: Re: [ietf-types] Request for review application/gml+xml

On 2012-01-11 08:05, Jan Algermissen wrote:
> Carl,
>
> On Jan 11, 2012, at 2:54 AM, Carl Reed wrote:
>
>> "version": If provided, this parameter indicates the GML version
>>     used in the GML document. Only the major and the first minor
>>     version number are provided, e.g. "3.2".
>>
>>     The value may be provided with or without quotes. i.e.,
>>     application/gml+xml; version=3.1 shall be treated as identical to
>>     application/gml+xml; version="3.1".
>>
>>     In cases where elements from multiple GML versions are used,
>>     the parameter shall indicate the highest GML version used in the
>>     document.
>>
>>     The parameter can be used to provide protocol-specific operations,
>>     such as version-based content negotiation in HTTP
>
> I cannot find the reference just now, but if I am not seriously wrong, media type parameters are not taken into account by HTTP conneg. (How could they, given that their meaning is defined by the media type itself except for q and charset et al.
> ...

Why would that be a problem?

See

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

Best regards, Julian

From: Jan Algermissen <[email-masked]>
Date: Wed, 11 Jan 2012 08:05:28 +0100
To: "Carl Reed" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review application/gml+xml

Carl,

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

> "version": If provided, this parameter indicates the GML version
>    used in the GML document. Only the major and the first minor
>    version number are provided, e.g. "3.2".
> =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

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

Jan

> or in the OGC
>    Web Feature Service.

From: "Carl Reed" <[email-masked]>
To: <[email-masked]>
Date: Tue, 10 Jan 2012 18:54:09 -0700
Importance: Normal
Subject: [ietf-types] Request for review application/gml+xml

This is a multi-part message in MIME format.

------=_NextPart_000_0312_01CCCFC9.3C9F49F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

Thank you for your time and consideration.

Carl Reed, PhD
CTO
OGC

Type name: Application

Subtype name: Standards Tree gml+xml

Required parameters:  None

Optional parameters:
   "charset" The charset parameter of application/gml+xml is=20
   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.,=20
   application/gml+xml; version=3D3.1 shall be treated as identical to
   application/gml+xml; version=3D"3.1".

   In cases where elements from multiple GML versions are used,=20
   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=20
   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=3D37743

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

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

The OGC: Making Location Count!

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

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

"The important thing is not to stop questioning." -- Albert Einstein=20
"Security is mostly a superstition. It does not exist in nature. Life is =
either a daring adventure or nothing." -- Helen Keller 
------=_NextPart_000_0312_01CCCFC9.3C9F49F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">
<DIV>The OGC is requesting review of a proposed GML MIME type. Below is =
the=20
application formatted using the registration form.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you for your time and consideration.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Carl Reed, PhD</DIV>
<DIV>CTO</DIV>
<DIV>OGC</DIV>
<DIV>&nbsp;</DIV>
<DIV>Type name: Application</DIV>
<DIV>&nbsp;</DIV>
<DIV>Subtype name: Standards Tree gml+xml</DIV>
<DIV>&nbsp;</DIV>
<DIV>Required parameters:&nbsp; None</DIV>
<DIV>&nbsp;</DIV>
<DIV>Optional parameters:</DIV>
<DIV>&nbsp;&nbsp; "charset" The charset parameter of application/gml+xml =
is=20
</DIV>
<DIV>&nbsp;&nbsp; handled in the same fashion as for application/xml, as =

specified</DIV>
<DIV>&nbsp;&nbsp; in Section 3.2 of [RFC3023]</DIV>
<DIV>&nbsp;&nbsp; </DIV>
<DIV>&nbsp;&nbsp; "version": If provided, this parameter indicates the =
GML=20
version</DIV>
<DIV>&nbsp;&nbsp; used in the GML document. Only the major and the first =

minor</DIV>
<DIV>&nbsp;&nbsp; version number are provided, e.g. "3.2". </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; The value may be provided with or without quotes. =
i.e., </DIV>
<DIV>&nbsp;&nbsp; application/gml+xml; version=3D3.1 shall be treated as =
identical=20
to</DIV>
<DIV>&nbsp;&nbsp; application/gml+xml; version=3D"3.1".</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; In cases where elements from multiple GML versions are =
used,=20
</DIV>
<DIV>&nbsp;&nbsp; the parameter shall indicate the highest GML version =
used in=20
the</DIV>
<DIV>&nbsp;&nbsp; document.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; The parameter can be used to provide protocol-specific =

operations,</DIV>
<DIV>&nbsp;&nbsp; such as version-based content negotiation in HTTP or =
in the=20
OGC </DIV>
<DIV>&nbsp;&nbsp; Web Feature Service.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Encoding considerations: As per Section 3.2 of [RFC3023]</DIV>
<DIV>&nbsp;</DIV>
<DIV>Security considerations:</DIV>
<DIV>&nbsp;&nbsp; The OGC Geography Markup Language (GML) is a generic =
format=20
for</DIV>
<DIV>&nbsp;&nbsp; exchanging geographic information, but application =
designers=20
must</DIV>
<DIV>&nbsp;&nbsp; not assume that it provides generic protection against =

security</DIV>
<DIV>&nbsp;&nbsp; threats.&nbsp; RFC 3023, section 10, discusses =
security=20
concerns for</DIV>
<DIV>&nbsp;&nbsp; generic XML, which are also applicable to GML.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; Xlink references in GML documents may cause arbitrary =
URIs to=20
be</DIV>
<DIV>&nbsp;&nbsp; dereferenced. In this case, the security issues of RFC =

3986,</DIV>
<DIV>&nbsp;&nbsp; section 7, should be considered.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Interoperability considerations:</DIV>
<DIV>&nbsp;&nbsp; Different versions of GML specify different XML Schema =

documents used</DIV>
<DIV>&nbsp;&nbsp; for the validation of GML documents. Starting with =
version=20
3.2, the</DIV>
<DIV>&nbsp;&nbsp; GML version information is represented in the =
namespace.=20
As</DIV>
<DIV>&nbsp;&nbsp; applications may only support a subset of all =
published=20
GML</DIV>
<DIV>&nbsp;&nbsp; versions, the use of the version parameter is=20
recommended.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Published specification :</DIV>
<DIV>&nbsp;&nbsp; GML (Geography Markup Language) is an international=20
standard</DIV>
<DIV>&nbsp;&nbsp; adopted by both the Open Geospatial Consortium (OGC) =
and</DIV>
<DIV>&nbsp;&nbsp; International Organization for Standardization (ISO). =
The=20
latest</DIV>
<DIV>&nbsp;&nbsp; version at the time of this writing is 3.2.1 which is=20
published by</DIV>
<DIV>&nbsp;&nbsp; ISO as ISO 19136:2007. The standard can be accessed =
freely=20
online at</DIV>
<DIV>&nbsp;&nbsp; <A=20
href=3D"http://www.opengeospatial.org/standards/gml">http://www.opengeosp=
atial.org/standards/gml</A>.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; The OGC GML MIME specification has also been approved =
by the=20
OGC</DIV>
<DIV>&nbsp;&nbsp; Membership and is published here:</DIV>
<DIV>&nbsp;&nbsp; <A=20
href=3D"http://portal.opengeospatial.org/files/?artifact_id=3D37743">http=
://portal.opengeospatial.org/files/?artifact_id=3D37743</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Applications which use this media type:</DIV>
<DIV>&nbsp;&nbsp; GML is a generic device-, platform-, and =
vendor-neutral=20
XML</DIV>
<DIV>&nbsp;&nbsp; grammar and is supported by a range of applications=20
creating,</DIV>
<DIV>&nbsp;&nbsp; providing access to and processing geographic =
information. The=20
use</DIV>
<DIV>&nbsp;&nbsp; of GML is in use internationally with hundreds of=20
deployed</DIV>
<DIV>&nbsp;&nbsp; applications able to create and ingest GML payloads, =
including=20
all</DIV>
<DIV>&nbsp;&nbsp; of the major GIS vendors, many database providers, =
earth=20
browzer</DIV>
<DIV>&nbsp;&nbsp; applications, and so forth.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Additional information:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. Magic number(s):&nbsp;&nbsp;&nbsp; None. Although no byte =
sequences can=20
be</DIV>
<DIV>&nbsp;&nbsp;&nbsp; counted on to consistently identify GML =
documents,=20
GML</DIV>
<DIV>&nbsp;&nbsp;&nbsp; documents will have the sequence <A=20
href=3D"http://www.opengis.net/gml">http://www.opengis.net/gml</A></DIV>
<DIV>&nbsp;&nbsp;&nbsp; as part of a namespace declaration to identify =
the=20
GML</DIV>
<DIV>&nbsp;&nbsp;&nbsp; namespace. This will usually be towards the top =
of the=20
document.</DIV>
<DIV>2. File extension(s): .xml or .gml</DIV>
<DIV>3. Macintosh file type code: TEXT</DIV>
<DIV>4. Object Identifiers: None</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; The OGC is an international voluntary consensus=20
standards</DIV>
<DIV>&nbsp;&nbsp;&nbsp; organization focused on defining and maintaining =

standards that</DIV>
<DIV>&nbsp;&nbsp;&nbsp; enable interoperability for using geospatial =
content and=20
services</DIV>
<DIV>&nbsp;&nbsp;&nbsp; in any application that requires the use of =
geospatial=20
content or</DIV>
<DIV>&nbsp;&nbsp;&nbsp; services. The OGC website is=20
www.opengeospatial.org.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Person &amp; email address to contact for further =
information:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Name : Clemens Portele</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Address:Interactive Instruments, Bonn, =
Germany</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Email : [email-masked]</DIV>
<DIV>&nbsp;</DIV>
<DIV>Intended usage: Common</DIV>
<DIV>&nbsp;</DIV>
<DIV>Restrictions on usage:</DIV>
<DIV>&nbsp;&nbsp;&nbsp; None</DIV>
<DIV>&nbsp;</DIV>
<DIV>Author/Change controller:</DIV>
<DIV>&nbsp;&nbsp;&nbsp; The GML standard is a work product of the Open=20
Geospatial</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Consortium (OGC). The OGC and the GML Standards=20
Working</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Group have change control over the GML =
standard.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; MIME types for use in OGC standards and formats =
are=20
defined</DIV>
<DIV>&nbsp;&nbsp;&nbsp; by the OGC Members and discussed and approved by =
the=20
OGC</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Naming Authority (OGC-NA). The function and role =
of the=20
OGC-NA</DIV>
<DIV>&nbsp;&nbsp;&nbsp; is described in RFC 5165 and in the OGC Policies =
and=20
Procedures</DIV>
<DIV>&nbsp;&nbsp;&nbsp; here: <A=20
href=3D"http://portal.opengeospatial.org/files/?artifact_id=3D23325">http=
://portal.opengeospatial.org/files/?artifact_id=3D23325</A></DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">&nbsp;</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">Carl=20
Reed, PhD<BR>CTO and Executive Director Standards Program<BR>Open =
Geospatial=20
Consortium<BR>www.opengeospatial.org<BR><BR>The OGC: Making Location=20
Count!<BR><BR>---------------------<BR><BR>This communication, including =

attachments, is for the exclusive use of addressee and may contain =
proprietary,=20
confidential or privileged information. If you are not the intended =
recipient,=20
any use, copying, disclosure, dissemination or distribution is strictly=20
prohibited. If you are not the intended recipient, please notify the =
sender=20
immediately by return email and delete this communication and destroy =
all=20
copies.<BR><BR>"The important thing is not to stop questioning." -- =
Albert=20
Einstein <BR>"Security is mostly a superstition. It does not exist in =
nature.=20
Life is either a daring adventure or nothing." -- Helen Keller=20
</DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0312_01CCCFC9.3C9F49F0--