Subject: Registration of MIME media type application/vnd.surety.tokenstore
From: standards at surety.com (Greg Thompson)
Date: Tue Jan 3 16:22:30 2006

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain no executable
code.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] (Greg Thompson)
Date: Wed, 31 Oct 2001 11:40:55 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
Message-ID: <[email-masked]>

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain no executable
code.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

Sorry but I have only just been registered to this list so have missed all
comments except for Dan's email below. I seems that the archive for this
mailing list was not working when I accessed it. Could someone please direct
me to the primary archive (not a mirror), so I can see everyones comments.

Many thanks,
Leon.

-----Original Message-----
From: ext Dan Kohn [mailto:[email-masked]]
Sent: 31 October, 2001 10:08
To: 'Keith Moore'; [email-masked]; Hurst Leon
(NMP/Helsinki)
Cc: [email-masked]
Subject: RE: Registration of MIME media type
application/vnd.nokia-mrv+xml 

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] ([email-masked])
Date: Wed, 31 Oct 2001 15:49:20 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

Sorry but I have only just been registered to this list so have missed all
comments except for Dan's email below. I seems that the archive for this
mailing list was not working when I accessed it. Could someone please direct
me to the primary archive (not a mirror), so I can see everyones comments.

Many thanks,
Leon.

-----Original Message-----
From: ext Dan Kohn [mailto:[email-masked]]
Sent: 31 October, 2001 10:08
To: 'Keith Moore'; [email-masked]; Hurst Leon
(NMP/Helsinki)
Cc: [email-masked]
Subject: RE: Registration of MIME media type
application/vnd.nokia-mrv+xml 

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue Jan  3 16:22:30 2006
Subject: Changed list server software for ietf-types list
Message-ID: <[email-masked]>

I have changed the list software for the IETF-types list from majordomo 
running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no

You should not notice any change until you want to unsubscribe - although 
you will get a note every month telling you how to unsubscribe or change 
your subscription.

The addresses that were previously on the "allowed to post" list are now 
added to the list as "nomail" members - there are 2 ways of achieving this 
functionality in Mailman, and this is one of them. Comments sought.

The main reason for the change is to get an interface that is simpler for 
the list administrator to use when approving non-subscriber postings and 
deleting the (HUGE amounts of) spam sent to the list.

Thank you for your patience.

                        Harald Alvestrand

From: [email-masked] (Harald Alvestrand)
Date: Wed, 31 Oct 2001 10:30:31 +0100
Subject: Changed list server software for ietf-types list
Message-ID: <[email-masked]>

I have changed the list software for the IETF-types list from majordomo 
running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no

You should not notice any change until you want to unsubscribe - although 
you will get a note every month telling you how to unsubscribe or change 
your subscription.

The addresses that were previously on the "allowed to post" list are now 
added to the list as "nomail" members - there are 2 ways of achieving this 
functionality in Mailman, and this is one of them. Comments sought.

The main reason for the change is to get an interface that is simpler for 
the list administrator to use when approving non-subscriber postings and 
deleting the (HUGE amounts of) spam sent to the list.

Thank you for your patience.

                        Harald Alvestrand

From: dan at dankohn.com (Dan Kohn)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] (Dan Kohn)
Date: Wed, 31 Oct 2001 00:07:57 -0800
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] (Greg Thompson)
Date: Wed, 31 Oct 2001 11:40:55 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
Message-ID: <[email-masked]>

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain no executable
code.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] ([email-masked])
Date: Wed, 31 Oct 2001 15:49:20 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

Sorry but I have only just been registered to this list so have missed all
comments except for Dan's email below. I seems that the archive for this
mailing list was not working when I accessed it. Could someone please direct
me to the primary archive (not a mirror), so I can see everyones comments.

Many thanks,
Leon.

-----Original Message-----
From: ext Dan Kohn [mailto:[email-masked]]
Sent: 31 October, 2001 10:08
To: 'Keith Moore'; [email-masked]; Hurst Leon
(NMP/Helsinki)
Cc: [email-masked]
Subject: RE: Registration of MIME media type
application/vnd.nokia-mrv+xml 

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] (Harald Alvestrand)
Date: Wed, 31 Oct 2001 10:30:31 +0100
Subject: Changed list server software for ietf-types list
Message-ID: <[email-masked]>

I have changed the list software for the IETF-types list from majordomo 
running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no

You should not notice any change until you want to unsubscribe - although 
you will get a note every month telling you how to unsubscribe or change 
your subscription.

The addresses that were previously on the "allowed to post" list are now 
added to the list as "nomail" members - there are 2 ways of achieving this 
functionality in Mailman, and this is one of them. Comments sought.

The main reason for the change is to get an interface that is simpler for 
the list administrator to use when approving non-subscriber postings and 
deleting the (HUGE amounts of) spam sent to the list.

Thank you for your patience.

                        Harald Alvestrand

From: [email-masked] (Dan Kohn)
Date: Wed, 31 Oct 2001 00:07:57 -0800
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: standards at surety.com (Greg Thompson)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.surety.tokenstore
Message-ID: <[email-masked]>

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain no executable
code.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] (Greg Thompson)
Date: Wed, 31 Oct 2001 11:40:55 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
Message-ID: <[email-masked]>

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain no executable
code.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

Sorry but I have only just been registered to this list so have missed all
comments except for Dan's email below. I seems that the archive for this
mailing list was not working when I accessed it. Could someone please direct
me to the primary archive (not a mirror), so I can see everyones comments.

Many thanks,
Leon.

-----Original Message-----
From: ext Dan Kohn [mailto:[email-masked]]
Sent: 31 October, 2001 10:08
To: 'Keith Moore'; [email-masked]; Hurst Leon
(NMP/Helsinki)
Cc: [email-masked]
Subject: RE: Registration of MIME media type
application/vnd.nokia-mrv+xml 

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] ([email-masked])
Date: Wed, 31 Oct 2001 15:49:20 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

Sorry but I have only just been registered to this list so have missed all
comments except for Dan's email below. I seems that the archive for this
mailing list was not working when I accessed it. Could someone please direct
me to the primary archive (not a mirror), so I can see everyones comments.

Many thanks,
Leon.

-----Original Message-----
From: ext Dan Kohn [mailto:[email-masked]]
Sent: 31 October, 2001 10:08
To: 'Keith Moore'; [email-masked]; Hurst Leon
(NMP/Helsinki)
Cc: [email-masked]
Subject: RE: Registration of MIME media type
application/vnd.nokia-mrv+xml 

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue Jan  3 16:22:30 2006
Subject: Changed list server software for ietf-types list
Message-ID: <[email-masked]>

I have changed the list software for the IETF-types list from majordomo 
running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no

You should not notice any change until you want to unsubscribe - although 
you will get a note every month telling you how to unsubscribe or change 
your subscription.

The addresses that were previously on the "allowed to post" list are now 
added to the list as "nomail" members - there are 2 ways of achieving this 
functionality in Mailman, and this is one of them. Comments sought.

The main reason for the change is to get an interface that is simpler for 
the list administrator to use when approving non-subscriber postings and 
deleting the (HUGE amounts of) spam sent to the list.

Thank you for your patience.

                        Harald Alvestrand

From: [email-masked] (Harald Alvestrand)
Date: Wed, 31 Oct 2001 10:30:31 +0100
Subject: Changed list server software for ietf-types list
Message-ID: <[email-masked]>

I have changed the list software for the IETF-types list from majordomo 
running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no

You should not notice any change until you want to unsubscribe - although 
you will get a note every month telling you how to unsubscribe or change 
your subscription.

The addresses that were previously on the "allowed to post" list are now 
added to the list as "nomail" members - there are 2 ways of achieving this 
functionality in Mailman, and this is one of them. Comments sought.

The main reason for the change is to get an interface that is simpler for 
the list administrator to use when approving non-subscriber postings and 
deleting the (HUGE amounts of) spam sent to the list.

Thank you for your patience.

                        Harald Alvestrand

From: dan at dankohn.com (Dan Kohn)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith

From: [email-masked] (Dan Kohn)
Date: Wed, 31 Oct 2001 00:07:57 -0800
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

In addition, the registrant should (re?)read section 7.1 of RFC 3023,
and strongly consider referencing that document.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 09:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: Registration of MIME media type
application/vnd.nokia-mrv+xml 

there are lots of problems with this proposed registration.

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.

Keith