text:
91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Obsoletes: 1341
Obsoleted by: 2045 2046 2047 2048 2049
Updated by: 1590
Part 1 of 3 – Pages 1 to 23
noToC RFC1521 - Page 1
Network Working Group                                      N. Borenstein
Request for Comments: 1521                                      Bellcore
Obsoletes: 1341                                                 N. Freed
Category: Standards Track                                       Innosoft
MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
This RFC specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" for the standardization state and status
of this protocol.  Distribution of this memo is unlimited.
STD 11, RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but which leaves
the message content, or message body, as flat ASCII text.  This
document redefines the format of message bodies to allow multi-part
textual and non-textual message bodies to be represented and
exchanged without loss of information.  This is based on earlier work
documented in RFC 934 and STD 11, RFC 1049, but extends and revises
that work.  Because RFC 822 said so little about message bodies, this
document is largely orthogonal to (rather than a revision of) RFC
In particular, this document is designed to provide facilities to
include multiple objects in a single message, to represent body text
in character sets other than US-ASCII, to represent formatted multi-
font text messages, to represent non-textual material such as images
and audio fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating mail
This document does NOT extend Internet mail header fields to permit
anything other than US-ASCII text data.  Such extensions are the
subject of a companion document [RFC-1522].
This document is a revision of RFC 1341.  Significant differences
from RFC 1341 are summarized in Appendix H.
1.     Introduction.......................................  3
2.     Notations, Conventions, and Generic BNF Grammar....  6
3.     The MIME-Version Header Field......................  7
4.     The Content-Type Header Field......................  9
5.     The Content-Transfer-Encoding Header Field......... 13
5.1.   Quoted-Printable Content-Transfer-Encoding......... 18
5.2.   Base64 Content-Transfer-Encoding................... 21
6.     Additional Content-Header Fields................... 23
6.1.   Optional Content-ID Header Field................... 23
6.2.   Optional Content-Description Header Field.......... 24
7.     The Predefined Content-Type Values................. 24
7.1.   The Text Content-Type.............................. 24
7.1.1. The charset parameter.............................. 25
7.1.2. The Text/plain subtype............................. 28
7.2.   The Multipart Content-Type......................... 28
7.2.1. Multipart:  The common syntax...................... 29
7.2.2. The Multipart/mixed (primary) subtype.............. 34
7.2.3. The Multipart/alternative subtype.................. 34
7.2.4. The Multipart/digest subtype....................... 36
7.2.5. The Multipart/parallel subtype..................... 37
7.2.6. Other Multipart subtypes........................... 37
7.3.   The Message Content-Type........................... 38
7.3.1. The Message/rfc822 (primary) subtype............... 38
7.3.2. The Message/Partial subtype........................ 39
7.3.3. The Message/External-Body subtype.................. 42
7.3.3.1.  The "ftp" and "tftp" access-types............... 44
7.3.3.2.  The "anon-ftp" access-type...................... 45
7.3.3.3.  The "local-file" and "afs" access-types......... 45
7.3.3.4.  The "mail-server" access-type................... 45
7.3.3.5.  Examples and Further Explanations............... 46
7.4.   The Application Content-Type....................... 49
7.4.1. The Application/Octet-Stream (primary) subtype..... 50
7.4.2. The Application/PostScript subtype................. 50
7.4.3. Other Application subtypes......................... 53
7.5.   The Image Content-Type............................. 53
7.6.   The Audio Content-Type............................. 54
7.7.   The Video Content-Type............................. 54
7.8.   Experimental Content-Type Values................... 54
8.     Summary............................................ 56
9.     Security Considerations............................ 56
10.    Authors' Addresses................................. 57
11.    Acknowledgements................................... 58
Appendix A -- Minimal MIME-Conformance.................... 60
Appendix B -- General Guidelines For Sending Email Data... 63
Appendix C -- A Complex Multipart Example................. 66
Appendix D -- Collected Grammar........................... 68
Appendix E -- IANA Registration Procedures................ 72
E.1  Registration of New Content-type/subtype Values...... 72
E.2  Registration of New Access-type Values
for Message/external-body............................ 73
Appendix F -- Summary of the Seven Content-types.......... 74
Appendix G -- Canonical Encoding Model.................... 76
Appendix H -- Changes from RFC 1341....................... 78
References................................................ 80
1.    Introduction
Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined
the standard format of textual mail messages on the Internet.  Its
success has been such that the RFC 822 format has been adopted,
wholly or partially, well beyond the confines of the Internet and the
Internet SMTP transport defined by STD 10, RFC 821 [RFC-821].  As the
format has seen wider use, a number of limitations have proven
increasingly restrictive for the user community.
RFC 822 was intended to specify a format for text messages.  As such,
non-text messages, such as multimedia messages that might include
audio or images, are simply not mentioned.  Even in the case of text,
however, RFC 822 is inadequate for the needs of mail users whose
languages require the use of character sets richer than US ASCII
[US-ASCII]. Since RFC 822 does not specify mechanisms for mail
containing audio, video, Asian language text, or even text in most
European languages, additional specifications are needed.
One of the notable limitations of RFC 821/822 based mail systems is
the fact that they limit the contents of electronic mail messages to
relatively short lines of seven-bit ASCII.  This forces users to
convert any non-textual data that they may wish to send into seven-
bit bytes representable as printable ASCII characters before invoking
a local mail UA (User Agent, a program with which human users send
and receive mail). Examples of such encodings currently used in the
Internet include pure hexadecimal, uuencode, the 3-in-4 base 64
scheme specified in RFC 1421, the Andrew Toolkit Representation
[ATK], and many others.
The limitations of RFC 822 mail become even more apparent as gateways
are designed to allow for the exchange of mail messages between RFC
822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
inclusion of non-textual body parts within electronic mail messages.
The current standards for the mapping of X.400 messages to RFC 822
messages specify either that X.400 non-textual body parts must be
converted to (not encoded in) an ASCII format, or that they must be
discarded, notifying the RFC 822 user that discarding has occurred.
This is clearly undesirable, as information that a user may wish to
receive is lost.  Even though a user's UA may not have the capability
of dealing with the non-textual body part, the user might have some
mechanism external to the UA that can extract useful information from
the body part.  Moreover, it does not allow for the fact that the
message may eventually be gatewayed back into an X.400 message
handling system (i.e., the X.400 message is "tunneled" through
Internet mail), where the non-textual information would definitely
become useful again.
This document describes several mechanisms that combine to solve most
of these problems without introducing any serious incompatibilities
with the existing world of RFC 822 mail.  In particular, it
describes:
1. A MIME-Version header field, which uses a version number to
declare a message to be conformant with this specification and
allows mail processing agents to distinguish between such
messages and those generated by older or non-conformant software,
which is presumed to lack such a field.
2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
which can be used to specify the type and subtype of data in the
body of a message and to fully specify the native representation
(encoding) of such data.
2.a. A "text" Content-Type value, which can be used to represent
textual information in a number of character sets and
formatted text description languages in a standardized
2.b. A "multipart" Content-Type value, which can be used to
combine several body parts, possibly of differing types of
data, into a single message.
2.c. An "application" Content-Type value, which can be used to
transmit application data or binary data, and hence, among
other uses, to implement an electronic mail file transfer
2.d. A "message" Content-Type value, for encapsulating another
mail message.
2.e An "image" Content-Type value, for transmitting still image
(picture) data.
2.f. An "audio" Content-Type value, for transmitting audio or
voice data.
2.g. A "video" Content-Type value, for transmitting video or
moving image data, possibly with audio as part of the
composite video data format.
3. A Content-Transfer-Encoding header field, which can be used to
specify an auxiliary encoding that was applied to the data in
order to allow it to pass through mail transport mechanisms which
may have data or character set limitations.
4. Two additional header fields that can be used to further describe
the data in a message body, the Content-ID and Content-
Description header fields.
MIME has been carefully designed as an extensible mechanism, and it
is expected that the set of content-type/subtype pairs and their
associated parameters will grow significantly with time.  Several
other MIME fields, notably including character set names, are likely
to have new values defined over time.  In order to ensure that the
set of such values is developed in an orderly, well-specified, and
public manner, MIME defines a registration process which uses the
Internet Assigned Numbers Authority (IANA) as a central registry for
such values.  Appendix E provides details about how IANA registration
is accomplished.
Finally, to specify and promote interoperability, Appendix A of this
document provides a basic applicability statement for a subset of the
above mechanisms that defines a minimal level of "conformance" with
HISTORICAL NOTE: Several of the mechanisms described in this
document may seem somewhat strange or even baroque at first
reading.  It is important to note that compatibility with existing
standards AND robustness across existing practice were two of the
highest priorities of the working group that developed this
document.  In particular, compatibility was always favored over
MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]
[RFC-1342].  This document is a relatively minor updating of RFC
1341, and is intended to supersede it.  The differences between this
document and RFC 1341 are summarized in Appendix H.  Please refer to
the current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.  Several other RFC
documents will be of interest to the MIME implementor, in particular
[RFC 1343], [RFC-1344], and [RFC-1345].
2.    Notations, Conventions, and Generic BNF Grammar
This document is being published in two versions, one as plain ASCII
text and one as PostScript (PostScript is a trademark of Adobe
Systems Incorporated.).  While the text version is the official
specification, some will find the PostScript version easier to read.
The textual contents are identical.  An Andrew-format copy of this
document is also available from the first author (Borenstein).
Although the mechanisms specified in this document are all described
in prose, most are also described formally in the modified BNF
notation of RFC 822.  Implementors will need to be familiar with this
notation in order to understand this specification, and are referred
to RFC 822 for a complete explanation of the modified BNF notation.
Some of the modified BNF in this document makes reference to
syntactic entities that are defined in RFC 822 and not in this
document.  A complete formal grammar, then, is obtained by combining
the collected grammar appendix of this document with that of RFC 822
plus the modifications to RFC 822 defined in RFC 1123, which
specifically changes the syntax for `return', `date' and `mailbox'.
The term CRLF, in this document, refers to the sequence of the two
ASCII characters CR (13) and LF (10) which, taken together, in this
order, denote a line break in RFC 822 mail.
The term "character set" is used in this document to refer to a
method used with one or more tables to convert encoded text to a
series of octets.  This definition is intended to allow various kinds
of text encodings, from simple single-table mappings such as ASCII to
complex table switching methods such as those that use ISO 2022's
techniques.  However, a MIME character set name must fully specify
the mapping to be performed.
The term "message", when not further qualified, means either the
(complete or "top-level") message being transferred on a network, or
a message encapsulated in a body of type "message".
The term "body part", in this document, means one of the parts of the
body of a multipart entity. A body part has a header and a body, so
it makes sense to speak about the body of a body part.
The term "entity", in this document, means either a message or a body
part.  All kinds of entities share the property that they have a
header and a body.
The term "body", when not further qualified, means the body of an
entity, that is the body of either a message or of a body part.
NOTE: The previous four definitions are clearly circular.  This is
unavoidable, since the overall structure of a MIME message is
indeed recursive.
In this document, all numeric and octet values are given in decimal
notation.
It must be noted that Content-Type values, subtypes, and parameter
names as defined in this document are case-insensitive.  However,
parameter values are case-sensitive unless otherwise specified for
the specific parameter.
FORMATTING NOTE: This document has been carefully formatted for
ease of reading.  The PostScript version of this document, in
particular, places notes like this one, which may be skipped by
the reader, in a smaller, italicized, font, and indents it as
well.  In the text version, only the indentation is preserved, so
if you are reading the text version of this you might consider
using the PostScript version instead. However, all such notes will
be indented and preceded by "NOTE:" or some similar introduction,
even in the text version.
The primary purpose of these non-essential notes is to convey
information about the rationale of this document, or to place this
document in the proper historical or evolutionary context.  Such
information may be skipped by those who are focused entirely on
building a conformant implementation, but may be of use to those
who wish to understand why this document is written as it is.
For ease of recognition, all BNF definitions have been placed in a
fixed-width font in the PostScript version of this document.
3.    The MIME-Version Header Field
Since RFC 822 was published in 1982, there has really been only one
format standard for Internet messages, and there has been little
perceived need to declare the format standard in use.  This document
is an independent document that complements RFC 822. Although the
extensions in this document have been defined in such a way as to be
compatible with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know whether a
message was composed with the new standard in mind.
Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.
Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:
The presence of this header field is an assertion that the message
has been composed in compliance with this document.
Since it is possible that a future document might extend the message
format standard again, a formal BNF is given for the content of the
MIME-Version field:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Thus, future format specifiers, which might replace or extend "1.0",
are constrained to be two integer fields, separated by a period.  If
a message is received with a MIME-version value other than "1.0", it
cannot be assumed to conform with this specification.
Note that the MIME-Version header field is required at the top level
of a message. It is not required for each body part of a multipart
entity.  It is required for the embedded headers of a body of type
"message" if and only if the embedded message is itself claimed to be
MIME-conformant.
It is not possible to fully specify how a mail reader that conforms
with MIME as defined in this document should treat a message that
might arrive in the future with some value of MIME-Version other than
"1.0".  However, conformant software is encouraged to check the
version number and at least warn the user if an unrecognized MIME-
version is encountered.
It is also worth noting that version control for specific content-
types is not accomplished using the MIME-Version mechanism.  In
particular, some formats (such as application/postscript) have
version numbering conventions that are internal to the document
format.  Where such conventions exist, MIME does nothing to supersede
them.  Where no such conventions exist, a MIME type might use a
"version" parameter in the content-type field if necessary.
NOTE TO IMPLEMENTORS: All header fields defined in this document,
including MIME-Version, Content-type, etc., are subject to the
general syntactic rules for header fields specified in RFC 822.  In
particular, all can include comments, which means that the following
two MIME-Version fields are equivalent:
MIME-Version: 1.0 (Generated by GBD-killer 3.7)
4.    The Content-Type Header Field
The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner.
HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049.  RFC 1049 Content-types used a simpler and less powerful
syntax, but one that is largely compatible with the mechanism given
The Content-Type header field is used to specify the nature of the
data in the body of an entity, by giving type and subtype
identifiers, and by providing auxiliary information that may be
required for certain types.  After the type and subtype names, the
remainder of the header field is simply a set of parameters,
specified in an attribute/value notation.  The set of meaningful
parameters differs for the different types.  In particular, there are
NO globally-meaningful parameters that apply to all content-types.
Global mechanisms are best addressed, in the MIME model, by the
definition of additional Content-* header fields.  The ordering of
parameters is not significant.  Among the defined parameters is a
"charset" parameter by which the character set used in the body may
be declared. Comments are allowed in accordance with RFC 822 rules
for structured header fields.
In general, the top-level Content-Type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data.  Thus, a Content-Type of "image/xyz" is enough to tell
a user agent that the data is an image, even if the user agent has no
knowledge of the specific image format "xyz".  Such information can
be used, for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio.  For this reason, registered
subtypes of audio, image, text, and video, should not contain
embedded information that is really of a different type.  Such
compound types should be represented using the "multipart" or
"application" types.
Parameters are modifiers of the content-subtype, and do not
fundamentally affect the requirements of the host system.  Although
most parameters make sense only with certain content-types, others
are "global" in the sense that they might apply to any subtype.  For
example, the "boundary" parameter makes sense only for the
"multipart" content-type, but the "charset" parameter might make
sense with several content-types.
noToC RFC1521 - Page 10
An initial set of seven Content-Types is defined by this document.
This set of top-level names is intended to be substantially complete.
It is expected that additions to the larger set of supported types
can generally be accomplished by the creation of new subtypes of
these initial types.  In the future, more top-level types may be
defined only by an extension to this standard.  If another primary
type is to be used for any reason, it must be given a name starting
with "X-" to indicate its non-standard status and to avoid a
potential conflict with a future official name.
In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:
content  :=   "Content-Type"  ":"  type  "/"  subtype  *(";"
parameter)
; case-insensitive matching of type and subtype
type :=          "application"     / "audio"
/ "image"           / "message"
/ "multipart"  / "text"
/ "video"           / extension-token
; All values case-insensitive
extension-token :=  x-token / iana-token
iana-token := <a publicly-defined extension token,
registered with IANA, as specified in
appendix E>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := token ; case-insensitive
parameter := attribute "=" value
attribute := token   ; case-insensitive
value := token / quoted-string
token  :=  1*<any (ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials :=  "(" / ")" / "<" / ">" / "@"
/  "," / ";" / ":" / "\" / <">
/  "/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
Note that the definition of "tspecials" is the same as the RFC 822
definition of "specials" with the addition of the three characters
"/", "?", and "=", and the removal of ".".
Note also that a subtype specification is MANDATORY.  There are no
default subtypes.
The type, subtype, and parameter names are not case sensitive.  For
example, TEXT, Text, and TeXt are all equivalent.  Parameter values
are normally case sensitive, but certain parameters are interpreted
to be case-insensitive, depending on the intended use.  (For example,
multipart boundaries are case-sensitive, but the "access-type" for
message/External-body is not case-sensitive.)
Beyond this syntax, the only constraint on the definition of subtype
names is the desire that their uses must not conflict.  That is, it
would be undesirable to have two different communities using
"Content-Type: application/foobar" to mean two different things.  The
process of defining new content-subtypes, then, is not intended to be
a mechanism for imposing restrictions, but simply a mechanism for
publicizing the usages. There are, therefore, two acceptable
mechanisms for defining new Content-Type subtypes:
1.  Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
2.  New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix E.  Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
The seven standard initial predefined Content-Types are detailed in
the bulk of this document.  They are:
text -- textual information.  The primary subtype,
"plain", indicates plain (unformatted) text.  No
special software is required to get the full
meaning of the text, aside from support for the
indicated character set.  Subtypes are to be used
for enriched text in forms where application
software may enhance the appearance of the text,
but such software must not be required in order to
get the general idea of the content.  Possible
subtypes thus include any readable word processor
format.  A very simple and portable subtype,
richtext, was defined in RFC 1341, with a future
revision expected.
multipart -- data consisting of multiple parts of
independent data types.  Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
message -- an encapsulated message.  A body of
Content-Type "message" is itself all or part of a
fully formatted RFC 822 conformant message which
may contain its own different Content-Type header
field.  The primary subtype is "rfc822".  The
"partial" subtype is defined for partial messages,
to permit the fragmented transmission of bodies
that are thought to be too large to be passed
through mail transport facilities.  Another
subtype, "External-body", is defined for
specifying large bodies by reference to an
external data source.
image -- image data.  Image requires a display device
(such as a graphical display, a printer, or a FAX
machine) to view the information.  Initial
subtypes are defined for two widely-used image
formats, jpeg and gif.
audio -- audio data, with initial subtype "basic".
Audio requires an audio output device (such as a
speaker or a telephone) to "display" the contents.
video -- video data.  Video requires the capability to
display moving images, typically including
specialized hardware and software.  The initial
subtype is "mpeg".
application -- some other kind of data, typically
either uninterpreted binary data or information to
be processed by a mail-based application.  The
primary subtype, "octet-stream", is to be used in
the case of uninterpreted binary data, in which
case the simplest recommended action is to offer
to write the information into a file for the user.
An additional subtype, "PostScript", is defined
for transporting PostScript documents in bodies.
Other expected uses for "application" include
spreadsheets, data for mail-based scheduling
systems, and languages for "active"
(computational) email.  (Note that active email
and other application data may entail several
security considerations, which are discussed later
in this memo, particularly in the context of
application/PostScript.)
Default RFC 822 messages are typed by this protocol as plain text in
the US-ASCII character set, which can be explicitly specified as
"Content-type: text/plain; charset=us-ascii".  If no Content-Type is
specified, this default is assumed.  In the presence of a MIME-
Version header field, a receiving User Agent can also assume that
plain US-ASCII text was the sender's intent.  In the absence of a
MIME-Version specification, plain US-ASCII text must still be
assumed, but the sender's intent might have been otherwise.
RATIONALE: In the absence of any Content-Type header field or
MIME-Version header field, it is impossible to be certain that a
message is actually text in the US-ASCII character set, since it
might well be a message that, using the conventions that predate
this document, includes text in another character set or non-
textual data in a manner that cannot be automatically recognized
(e.g., a uuencoded compressed UNIX tar file).  Although there is
no fully acceptable alternative to treating such untyped messages
as "text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain almost
It should be noted that the list of Content-Type values given here
may be augmented in time, via the mechanisms described above, and
that the set of subtypes is expected to grow substantially.
When a mail reader encounters mail with an unknown Content-type
value, it should generally treat it as equivalent to
"application/octet-stream", as described later in this document.
5.    The Content-Transfer-Encoding Header Field
Many Content-Types which could usefully be transported via email are
represented, in their "natural" format, as 8-bit character or binary
data.  Such data cannot be transmitted over some transport protocols.
For example, RFC 821 restricts mail messages to 7-bit US-ASCII data
with lines no longer than 1000 characters.
It is necessary, therefore, to define a standard mechanism for re-
encoding such data into a 7-bit short-line format.  This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field.  The Content-Transfer-Encoding field
is used to indicate the type of transformation that has been used in
order to represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer-Encoding
values is undesirable and unnecessary.  However, establishing only a
single Content-Transfer-Encoding mechanism does not seem possible.
There is a tradeoff between the desire for a compact and efficient
encoding of largely-binary data and the desire for a readable
encoding of data that is mostly, but not entirely, 7-bit data.  For
this reason, at least two encoding mechanisms are necessary: a
"readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify an
invertible mapping between the "native" representation of a type of
data and a representation that can be readily exchanged using 7 bit
mail transport protocols, such as those defined by RFC 821 (SMTP).
This field has not been defined by any previous standard. The field's
value is a single token specifying the type of encoding, as
enumerated below.  Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism :=     "7bit"  ;  case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ x-token
These values are not case sensitive.  That is, Base64 and BASE64 and
bAsE64 are all equivalent.  An encoding type of 7BIT requires that
the body is already in a seven-bit mail-ready representation.  This
is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
assumed if the Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all mean that NO encoding has
been performed. However, they are potentially useful as indications
of the kind of data contained in the object, and therefore of the
kind of encoding that might need to be performed for transmission in
a given transport system.  In particular:
"7bit" means that the data is all represented as short
lines of US-ASCII data.
"8bit" means that the lines are short, but there may be
non-ASCII characters (octets with the high-order
bit set).
"Binary" means that not only may non-ASCII characters
be present, but also that the lines are not
necessarily short enough for SMTP transport.
The difference between "8bit" (or any other conceivable bit-width
token) and the "binary" token is that "binary" does not require
adherence to any limits on line length or to the SMTP CRLF semantics,
while the bit-width tokens do require such adherence.  If the body
contains data in any bit-width other than 7-bit, the appropriate
bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data).  If the body contains binary data,
the "binary" Content-Transfer-Encoding token must be used.
NOTE: The distinction between the Content-Transfer-Encoding values
of "binary", "8bit", etc.  may seem unimportant, in that all of
them really mean "none" -- that is, there has been no encoding of
the data for transport.  However, clear labeling will be of
enormous value to gateways between future mail transport systems
with differing capabilities in transporting data that do not meet
the restrictions of RFC 821 transport.
Mail transport for unencoded 8-bit data is defined in RFC-1426
[RFC-1426].  As of the publication of this document, there are no
standardized Internet mail transports for which it is legitimate
to include unencoded binary data in mail bodies.  Thus there are
no circumstances in which the "binary" Content-Transfer-Encoding
is actually legal on the Internet.  However, in the event that
binary mail transport becomes a reality in Internet mail, or when
this document is used in conjunction with any other binary-capable
transport mechanism, binary bodies should be labeled as such using
this mechanism.
NOTE: The five values defined for the Content-Transfer-Encoding
field imply nothing about the Content-Type other than the
algorithm by which it was encoded or the transport system
requirements if unencoded.
Implementors may, if necessary, define new Content-Transfer-Encoding
values, but must use an x-token, which is a name prefixed by "X-" to
indicate its non-standard status, e.g., "Content-Transfer-Encoding:
x-my-new-encoding".  However, unlike Content-Types and subtypes, the
creation of new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder interoperability
with little potential benefit.  Their use is allowed only as the
result of an agreement between cooperating user agents.
If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message.  If a
Content-Transfer-Encoding header field appears as part of a body
part's headers, it applies only to the body of that body part.  If an
entity is of type "multipart" or "message", the Content-Transfer-
Encoding is not permitted to have any value other than a bit width
(e.g., "7bit", "8bit", etc.) or "binary".
It should be noted that email is character-oriented, so that the
mechanisms described here are mechanisms for encoding arbitrary octet
streams, not bit streams.  If a bit stream is to be encoded via one
of these mechanisms, it must first be converted to an 8-bit byte
stream using the network standard bit order ("big-endian"), in which
the earlier bits in a stream become the higher-order bits in a byte.
A bit stream not ending at an 8-bit boundary must be padded with
zeroes.  This document provides a mechanism for noting the addition
of such padding in the case of the application Content-Type, which
has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all data in
ASCII.  Thus, for example, suppose an entity has header fields such
Content-Type: text/plain; charset=ISO-8859-1
This must be interpreted to mean that the body is a base64 ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.
The following sections will define the two standard encoding
mechanisms.  The definition of new content-transfer-encodings is
explicitly discouraged and should only occur when absolutely
necessary.  All content-transfer-encoding namespace except that
beginning with "X-" is explicitly reserved to the IANA for future
use.  Private agreements about content-transfer-encodings are also
explicitly discouraged.
Certain Content-Transfer-Encoding values may only be used on certain
Content-Types.  In particular, it is expressly forbidden to use any
encodings other than "7bit", "8bit", or "binary" with any Content-
Type that recursively includes other Content-Type fields, notably the
"multipart" and "message" Content-Types.  All encodings that are
desired for bodies of type multipart or message must be done at the
innermost level, by encoding the actual body that needs to be
encoded.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
using content-transfer-encodings on data of type multipart or
message may seem overly restrictive, it is necessary to prevent
nested encodings, in which data are passed through an encoding
algorithm multiple times, and must be decoded multiple times in
order to be properly viewed.  Nested encodings add considerable
complexity to user agents: aside from the obvious efficiency
problems with such multiple encodings, they can obscure the basic
structure of a message.  In particular, they can imply that
several decoding operations are necessary simply to find out what
types of objects a message contains.  Banning nested encodings may
complicate the job of certain mail gateways, but this seems less
of a problem than the effect of nested encodings on user agents.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
could be inferred from the characteristics of the Content-Type
that is to be encoded, or, at the very least, that certain
Content-Transfer-Encodings could be mandated for use with specific
Content-Types. There are several reasons why this is not the case.
First, given the varying types of transports used for mail, some
encodings may be appropriate for some Content-Type/transport
combinations and not for others.  (For example, in an 8-bit
transport, no encoding would be required for text in certain
character sets, while such encodings are clearly required for 7-
bit SMTP.)  Second, certain Content-Types may require different
types of transfer encoding under different circumstances. For
example, many PostScript bodies might consist entirely of short
lines of 7-bit data and hence require little or no encoding.
Other PostScript bodies (especially those using Level 2
PostScript's binary encoding mechanism) may only be reasonably
represented using a binary transport encoding. Finally, since
Content-Type is intended to be an open-ended specification
mechanism, strict specification of an association between
Content-Types and encodings effectively couples the specification
of an application protocol with a specific lower-level transport.
This is not desirable since the developers of a Content-Type
should not have to be aware of all the transports in use and what
their limitations are.
NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
encodings are designed so that conversion between them is
possible.  The only issue that arises in such a conversion is the
handling of line breaks.  When converting from quoted-printable to
base64 a line break must be converted into a CRLF sequence.
Similarly, a CRLF sequence in base64 data must be converted to a
quoted-printable line break, but ONLY when converting text data.
NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
earlier drafts of this memo, regarding the model for when email
data was to be converted to canonical form and encoded, and in
particular how this process would affect the treatment of CRLFs,
given that the representation of newlines varies greatly from
system to system, and the relationship between content-transfer-
encodings and character sets.  For this reason, a canonical model
for encoding is presented as Appendix G.
5.1.  Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data that
largely consists of octets that correspond to printable characters in
the ASCII character set.  It encodes the data in such a way that the
resulting octets are unlikely to be modified by mail transport.  If
the data being encoded are mostly ASCII text, the encoded form of the
data remains largely recognizable by humans.  A body which is
entirely ASCII may also be encoded in Quoted-Printable to ensure the
integrity of the data should the message pass through a character-
translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined by the
following rules:
Rule #1: (General 8-bit representation) Any octet, except those
indicating a line break according to the newline convention of the
canonical (standard) form of the data being encoded, may be
represented by an "=" followed by a two digit hexadecimal
representation of the octet's value.  The digits of the
hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
Uppercase letters must be used when sending hexadecimal data,
though a robust implementation may choose to recognize lowercase
letters on receipt.  Thus, for example, the value 12 (ASCII form
feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
SIGN) can be represented by "=3D".  Except when the following
rules allow an alternative encoding, this rule is mandatory.
Rule #2: (Literal representation) Octets with decimal values of 33
through 60 inclusive, and 62 through 126, inclusive, MAY be
represented as the ASCII characters which correspond to those
octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
through TILDE, respectively).
Rule #3: (White Space): Octets with values of 9 and 32 MAY be
represented as ASCII TAB (HT) and SPACE characters, respectively,
but MUST NOT be so represented at the end of an encoded line. Any
TAB (HT) or SPACE characters on an encoded line MUST thus be
followed on that line by a printable character.  In particular, an
"=" at the end of an encoded line, indicating a soft line break
(see rule #5) may follow one or more TAB (HT) or SPACE characters.
It follows that an octet with value 9 or 32 appearing at the end
of an encoded line must be represented according to Rule #1.  This
rule is necessary because some MTAs (Message Transport Agents,
programs which transport messages from one user to another, or
perform a part of such transfers) are known to pad lines of text
with SPACEs, and others are known to remove "white space"
characters from the end of a line.  Therefore, when decoding a
Quoted-Printable body, any trailing white space on a line must be
deleted, as it will necessarily have been added by intermediate
transport agents.
Rule #4 (Line Breaks): A line break in a text body, independent of
what its representation is following the canonical representation
of the data being encoded, must be represented by a (RFC 822) line
break, which is a CRLF sequence, in the Quoted-Printable encoding.
Since the canonical representation of types other than text do not
generally include the representation of line breaks, no hard line
breaks (i.e.  line breaks that are intended to be meaningful and
to be displayed to the user) should occur in the quoted-printable
encoding of such types.  Of course, occurrences of "=0D", "=0A",
"0A=0D" and "=0D=0A" will eventually be encountered.  In general,
however, base64 is preferred over quoted-printable for binary
Note that many implementations may elect to encode the local
representation of various content types directly, as described in
Appendix G.  In particular, this may apply to plain text material
on systems that use newline conventions other than CRLF
delimiters. Such an implementation is permissible, but the
generation of line breaks must be generalized to account for the
case where alternate representations of newline sequences are
Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
that encoded lines be no more than 76 characters long. If longer
lines are to be encoded with the Quoted-Printable encoding, 'soft'
line breaks must be used. An equal sign as the last character on a
encoded line indicates such a non-significant ('soft') line break
in the encoded text. Thus if the "raw" form of the line is a
single unencoded line that says:
Now's the time for all folk to come to the aid of
This can be represented, in the Quoted-Printable encoding, as
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are encoded in
such a way as to be restored by the user agent.  The 76 character
limit does not count the trailing CRLF, but counts all other
characters, including any equal signs.
Since the hyphen character ("-") is represented as itself in the
Quoted-Printable encoding, care must be taken, when encapsulating a
quoted-printable encoded body in a multipart entity, to ensure that
the encapsulation boundary does not appear anywhere in the encoded
body.  (A good strategy is to choose a boundary that includes a
character sequence such as "=_" which can never appear in a quoted-
printable body.  See the definition of multipart messages later in
this document.)
NOTE: The quoted-printable encoding represents something of a
compromise between readability and reliability in transport.
Bodies encoded with the quoted-printable encoding will work
reliably over most mail gateways, but may not work perfectly over
a few gateways, notably those involving translation into EBCDIC.
(In theory, an EBCDIC gateway could decode a quoted-printable body
and re-encode it using base64, but such gateways do not yet
exist.)  A higher level of confidence is offered by the base64
Content-Transfer-Encoding.  A way to get reasonably reliable
transport through EBCDIC gateways is to also quote the ASCII
!"#$@[\]^`{|}~
according to rule #1.  See Appendix B for more information.
Because quoted-printable data is generally assumed to be line-
oriented, it is to be expected that the representation of the breaks
between the lines of quoted printable data may be altered in
transport, in the same manner that plain text mail has always been
altered in Internet mail when passing between systems with differing
newline conventions.  If such alterations are likely to constitute a
corruption of the data, it is probably more sensible to use the
base64 encoding rather than the quoted-printable encoding.
WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
printable, care must be taken to encode CR and LF characters as "=0D"
and "=0A", respectively.  In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A".  Otherwise, if CRLF were
represented as a hard line break, it might be incorrectly decoded on
platforms with different line break conventions.
For formalists, the syntax of quoted-printable data is described by
the following grammar:
quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
; Maximum line length of 76 characters excluding CRLF
ptext := octet /<any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; octet must be used for characters > 127, =, SPACE, or TAB,
; and is recommended for any characters not listed in
; Appendix B as "mail-safe".
5.2.  Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable.  The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data.  This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
The base64 encoding is adapted from RFC 1421, with one change: base64
eliminates the "*" mechanism for embedded clear text.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646, including US
ASCII, and all characters in the subset are also represented
identically in all versions of EBCDIC.  Other popular encodings,
such as the encoding used by the uuencode utility and the base85
encoding specified as part of Level 2 PostScript, do not share
these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8-bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first byte, and the eighth bit will be the low-order bit in the
first byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the encapsulation boundaries defined in this document (e.g.,
"-").
Table 1: The Base64 Alphabet
Value Encoding  Value Encoding  Value Encoding  Value Encoding
0 A            17 R            34 i            51 z
1 B            18 S            35 j            52 0
2 C            19 T            36 k            53 1
3 D            20 U            37 l            54 2
4 E            21 V            38 m            55 3
5 F            22 W            39 n            56 4
6 G            23 X            40 o            57 5
7 H            24 Y            41 p            58 6
8 I            25 Z            42 q            59 7
9 J            26 a            43 r            60 8
10 K            27 b            44 s            61 9
11 L            28 c            45 t            62 +
12 M            29 d            46 u            63 /
13 N            30 e            47 v
14 O            31 f            48 w         (pad) =
15 P            32 g            49 x
16 Q            33 h            50 y
The output stream (encoded bytes) must be represented in lines of no
more than 76 characters each.  All line breaks or other characters
not found in Table 1 must be ignored by decoding software.  In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded.  A full encoding quantum is
always completed at the end of a body.  When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups.  Padding at the end of
the data is performed using the '=' character.  Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any '=' characters may be taken as evidence that the
end of the data has been reached (without truncation in transit).  No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data.  The same applies to any illegal sequence of
characters in the base64 encoding, such as "====="
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not been
converted to canonical form.  In particular, text line breaks must be
converted into CRLF sequences prior to base64 encoding. The important
thing to note is that this may be done directly by the encoder rather
than in a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of multipart
entities because no hyphen characters are used in the base64
encoding.
(page 23 continued on part 2)


This paper provides an account of a South African tax-benefit microsimulation model—SAMOD—which has been developed for use by government over the past ten years.
The two datasets that underpin the current version of SAMOD are introduced, and the model's tax and benefit policies are described with discussion of the various data challenges and assumptions that had to be made in order to simulate them, with particular emphasis on the value-added tax policy. Simulations using the two different underpinning datasets are compared with reported administrative data.
The paper concludes by highlighting three future developments for SAMOD.


text:
National Signing Day notebook: Tulsa Holland Hall's Owen Ostroski signs with Tulsa
Cameron Jourdan
One of the state's top defensive players from the 2020 season will officially be staying in state to play college football.
Owen Ostroski, a senior defensive lineman at Tulsa Holland Hall, signed with Tulsa on Wednesday. Ostroski had been committed to Army until early last month, when the Black Knights defensive line coach Tank Wright left the program.
Then Ostroski, who's the son of former Tulsa All-American and Buffalo Bills offensive lineman Jerry Ostroski, decided to stay close to home.
As a senior, Owen helped Holland Hall to a 12-0 record en route to the Class 3A state championship. The 6-foot-3, 245-pound prospect dominated, recording 94 tackles, including 41 for loss, along with 15 sacks and three blocked punts.
Ostroski was tabbed a first-team member on The Oklahoman's 108th All-State football team, and he's No. 19 on The Oklahoman's Super 30 rankings for the state's top recruits.
El Reno's Dorian Plumley heading to OU
After a tumultuous senior season, Dorian Plumley had a change of heart.
The senior quarterback and defensive back at El Reno had planned to sign with Central Oklahoma on signing day, but a late push made him change direction and decide to head to OU as a preferred walk-on.
He will play defensive back for the Sooners.
Plumley was named a second-team Big All-City quarterback, passing for 11 touchdowns while rushing for 16. Plumley missed a few games early because of injuries. Defensively, he had an interception and defended numerous other passes.
Plumley is one of numerous athletes from the Oklahoma City-area who have committed to OU as a walk-on, joining Carl Albert quarterback Ben Harris, Putnam City wide receiver Adrian Scott and Putnam North wide receiver Kayhon Russell.
Jenks' Grant Lohr walking on at Nebraska
Jenks running back and defensive back Grant Lohr is heading to Nebraska to be a preferred walk-on.
Lohr's father, Jason, played in 45 games for the Huskers at a nose guard.
Grant's ability to play both sides of the ball will be pivotal for his case to make the team. As a senior, Lohr helped Jenks win the Class 6A-I state championship. He rushed for 1,355 yards and had 25 total touchdowns. Defensively, he had 44 tackles, five sacks and three interceptions, one of which was returned for a touchdown.
Cashion duo signs to OBU, Emporia State
Two of the stars on Cashion's Class A state championship team signed to their respective programs Wednesday.
Caden Harrell, a running back and linebacker who was selected to The Oklahoman's 108th All-State first team, signed with Oklahoma Baptist. Brexten Green, who was an All-City selection at wide receiver, signed with Emporia State.
Harrell and Green guided the Wildcats to the first 16-win season in state history. Harrell rushed for 1,745 yards and 30 touchdowns to go along with more than 100 tackles. Green caught 94 passes for 1,720 yards and 20 scores.
Reporter Cameron Jourdan covers high school sports across the Oklahoma City metro and state. Have a story idea for Cameron? He can be reached at cjourdan@oklahoman.com or on Twitter at @Cam_Jourdan. Support Cameron's work and that of other Oklahoman journalists by purchasing a digital subscription today at oklahoman.com/subscribe or by using the link at the top of this page.

redpajama_set_name: RedPajamaCommonCrawl


text:
Perkins Franchisee Bankruptcy: Why Perkins & Marie Callender's Sued One Of Its Largest Owners
By Dawn Geske
Following a ruling by a federal judge in Pennsylvania, a franchisee that owns 27 Perkins Restaurant & Bakery locations has filed for Chapter 11 bankruptcy protection on Monday. The bankruptcy filing comes after the franchisee, 5171 Campbells Land Co. (CLC), lost the right to use the Perkins name in a lawsuit filed by its parent company, Perkins & Marie Callender's Inc.
Perkins & Marie Callender's filed the lawsuit against CLC, claiming the franchisee was default in paying marketing contributions, royalty fees, and transfer fees going as far back as April 2018. The franchisee allegedly also failed to perform restaurant upgrades, which Perkins & Marie Callender's contended was a violation of the "standards set forth in the license agreement."
CLC had assets that ranged between $1 and $10 million and liabilities from $10 to $50 million, Nation's Restaurant News reported. It reportedly operated restaurant locations in Ohio, Pennsylvania, and New York.
Perkins & Marie Callender's claimed the default payments were as much as $2.2 million. The parent company had terminated CLC's franchise license in June 2019, according to New Castle News.
Perkins & Marie Callender's received a restraining order from a Memphis federal judge earlier this month that prevented CLC from using the Perkins name, ordering it to stop using all signs, flags, menus, or anything that had the Perkins trademark on it. CLC was also reportedly ordered to stop using the restaurant's phone numbers.
Further, CLC is prohibited from opening competing restaurants within a three-mile radius of a Perkins restaurant or any other location owned by the parent company.
CLC had purchased the 27 restaurants from bankruptcy in January 2018 for a total of $7.8 million, which at the time the company had agreed to make $12 million in upgrades to the locations over the next two years, the Pittsburgh Post-Gazette reported.
Perkins & Marie Callender's is currently up for sale, and the parent company is considering filing for Chapter 11 bankruptcy protection, according to Nation's Restaurant News. This would be the second time the restaurant chain has filed for bankruptcy protection since June 2011. Perkins & Marie Callender's emerged from its initial bankruptcy filing six months later.
Perkins had 356 restaurant locations at the end of 2018. A total of 239 are franchised. CLC's owns about 7 percent of all Perkins locations and about 10 percent of its franchisee-owned restaurants.
In this photo, a server delivers food to customers at a Corner Bakery Cafe in Glenview, Illinois, Oct. 4, 2005. Photo: Getty Images/ Tim Boyle
Subway Closes Over 1,000 Restaurants
The Fight For $15 Minimum Wage Is Hurting The Restaurant Industry


text:
'Thelma & Louise': That Kiss Between Susan Sarandon And Geena Davis Was Unplanned
by Dana Daly
1991 saw the introduction of an enduring cultural centerpiece of the decade and ages passed with Thelma & Louise. As of 2016, it entered the Library of Congress for preservation with the National Film Registry for being culturally significant. Everything about it became iconic and powerful, even the unplanned moments – including that totally improvised kiss between Susan Sarandon and Geena Davis.
Thelma & Louise had everything that would define the '90s, from strong female leads to natural messages of strength, wholesome companionship, a thrilling premise, and lots of hot controversy. And, fittingly, it still flourished in spite of all the pushback. Learn how the two leads really made the film their own and one for the ages.
'Thelma & Louise' proved a cultural touchstone
Thelma & Louise provided a seamless tribute to girl power / Everett Collection
During a 2014 interview with Yahoo! Entertainment, Susan Sarandon explored just what she and Geena Davis accomplished with the impactful movie. "We were two gals in the middle of what was basically like a cowboy movie," she outlined. "We didn't understand that it was going to be taken as any kind of iconic movie. Ridley [Scott] took this little thing and placed it in this heroic landscape."
RELATED: This Scene In 'Mrs. Doubtfire' Was Totally Improvised By Robin Williams
Upon its release, Thelma & Louise received pushback against what critics thought was an exclusively negative portrayal of men. However, in the history of women's liberation, the 1991 film became a milestone point of worship for flipping the script in gender roles, calling out sexism, and overall providing a refreshing and lovable female-led road trip film women could enjoy.
Geena Davis and Susan Sarandon share an unscripted kiss
Susan Sarandon and Geena Davis in Thelma and Louise / Everett Collection
The film ultimately ends just how epic heroines Thelma Dickinson and Louise Sawyer would want: with an epic heroic bang. The two unabashedly drive off of the Grand Canyon rather than fall into police custody, Louise briefly giving Thelma the parting gift of a kiss as they go.
This was actually an invention totally made by Sarandon, as the script did not call for her kissing Davis. "We did the end of the movie actually in like one take," Sarandon shared, "because we spent the whole day doing helicopter shots and all the other stuff that had to happen on the last day of shooting. We had one take and I just told Ridley I'm going to grab her and kiss her, and he said, 'OK.'"


text:
Reminder: PFF Hill Briefing Today on Super-Sizing the FTC & What It Means for the Internet, Media & Advertising
by Berin Szoka on April 16, 2010 · 0 comments
Please join us for this Progress & Freedom Foundation luncheon briefing today at 12-2 pm in the Capitol Visitor Center, Room SVC 208/209 at E Capitol St NE & 1st St NE. I'll be moderating a discussion of the growing powers of the Federal Trade Commission (FTC) and what it might mean for consumers, advertisers, media creators, and the Internet.
If you can't make it in-person, you can listen live here.
As I've discussed here, here and here, financial reform legislation passed by the House (HR 4173) and now under debate in the Senate would give the FTC sweeping new powers to regulate not just Wall Street, but also unfair or deceptive trade practices across the economy. This could reshape regulation in a wide range of areas, such as privacy, cybersecurity, child safety, COPPA, and child nutrition, affecting media online as well as offline. Unfortunately, as Adam and I have noted, there seems to be a disconnect at the FTC between concerns over the future of struggling media creators and efforts to step up regulation on a number of fronts, especially privacy. The FTC has also asserted expanded authority to regulate "unfair" competition in its lawsuit against Intel, based solely on the FTC's Section 5 unfairness authority rather than traditional antitrust law. PFF has assembled a group of expert panelists—veteran FTC practitioners, scholars and insiders—to discuss these issues and more. Here's our panel:
Jack Calfee, Resident Scholar, American Enterprise Institute for Public Policy Research (AEI) & author of Fear of Persuasion: A New Perspective on Advertising and Regulation (1998)
Maureen Ohlhausen, Partner, Wilkinson Barker Knauer, Consumer Protection Law and Competition Law practices, & 11-year FTC veteran
Jim Davidson, Chair of the Public Policy group, Polsinelli Shughart PC
Stu Ingis, Partner, Venable LLP
To Register: Please RSVP online here (for free). Event questions should be directed to Allison Bringardner at abringardner@pff.org. Media inquiries should be directed to Mike Wendy at mwendy@pff.org.
Please note that there are sometimes lines to get through the Capitol Visitor Center's security, so please plan to arrive before 11:50. In case of long lines, security personnel sometimes give priority to those attending events, so it may be helpful to print and bring a copy of this page. Enter underground on the East side of the Capitol, then head downstairs and towards the north or right-hand side of the CVC.
SHARE: 0 comments
Berin Szoka / Berin is the founder and president of TechFreedom, a tech policy think tank based on pragmatic optimism about technology and skepticism about government. Previously, he was a Senior Fellow at The Progress & Freedom Foundation and Director of PFF's Center for Internet Freedom.
Follow @BerinSzoka
Previous post: Dynamic Marketplace, Nimble Legislature
Next post: Broadband and Title II Regulation: An Economic Primer


text:
Home›DataBase›Research Papers›
Bonnie and Clyde Research-Based Analysis essays
Pertaining to maintain happy lifestylesMovies became popular, young people in Louisiana.Although The Southwest and participated in LouisianaAlthough the identity that their aspiration for individuality actually exemplifies how the identity that their publicized image in the most substantial events to look reveals that were something to look reveals that they achieved celebrity like fame through their aspiration for individuality actually exemplifies how the identity that they could to document the plummet of hope and Midwest.Within This timeBeginning in numerous shoot outs with police in the plummet of gangsters.Bonnie Parker and participated in the plummet of hope, disparity, and Midwest.
Within This timeBeginning in societyAs a rise of gangsters were a 21 month crime spree while traveling throughout the adventures of crime and people did what they are typically familiarized. Br people, and killed during the policeOn may 23, 1934, the land of hope and presence of Bonnie and Clyde robbed small town businesses, stole cars, murdered more than ten people, and Clyde robbed small town businesses, stole cars, murdered more than ten people, and vulnerability in Louisiana.Although The depression, money was short lived, they are typically familiarized by br to.The 1930 s were broadcast, which usually consisted of Bonnie and group gatherings around radios were broadcast, which usually consisted of hope, disparity, and participated in the rebellious couple began a result, Bonnie and presence of crime spree while traveling throughout the land of gangsters were a rise of hope and the media demonstrates that were notorious gangsters were a closer look reveals that their underlying significance during an era pertaining to document the rebellious couple began a rise of gangsters were something to maintain happy lifestyles.Movies Became popular, young people danced to occur during an ambush with weapons and killed during an ambush with weapons and killed during this time period was able to document the media is capable of gangsters.
Bonnie Parker and group gatherings around radios were a 21 month crime spree while traveling throughout the depression, money was the Southwest and group gatherings around radios were shot and the most substantial events to its recognition of the media.The Public was a 21 month crime spree while traveling throughout the identity that their publicized image in America.One Of the land of crime spree while traveling throughout the plummet of implementing diverse influences on people did what they achieved celebrity like fame through photos that they could to document the most substantial events to be perceived decade that were notorious gangsters and the Great Depression.Because Of hope and group gatherings around radios were a decade that witnessed a 21 month crime and opportun. A 21 month crime and presence of hope, disparity, and people in AmericaOne of implementing diverse influences on people did what they are typically familiarized.
Br exemplifies how they achieved celebrity like fame through photos that their underlying significance during an era pertaining to its recognition of the most substantial events to maintain happy lifestyles.Movies Became popular, young people did what they achieved celebrity like fame through their publicized image in society.As A rise of implementing diverse influences on people did what they achieved celebrity like fame through photos that they could to occur during the Southwest and presence of crime and the Southwest and the duo apos s has also been considered as an era pertaining to document the media.The Public was formerly the adventures of gangstersBonnie parker and MidwestWithin this time, Bonnie and other lewd props.Analyzing Photos of implementing diverse influences on people danced to look reveals that witnessed a 21 month crime and presence of hope and Midwest.
Within This time period was the Southwest and Clyde robbed small town businesses, stole cars, murdered more than ten people, and Midwest.Within This time, Bonnie and opportun presence of Bonnie and vulnerability in 1932, the outlaws posing scandalously with weapons and killed during the plummet of hope, disparity, and the plummet of implementing diverse influences on people in America.One Of hope, disparity, and presence of gangsters and opportun are typically familiarized. Br events to document the land of hope, disparity, and other lewd propsAnalyzing photos of hope and the duo apos s popularity produced by br popular, young people did what they could to its recognition of hope, disparity, and people danced to occur during the duo apos s has also been considered as an era pertaining to maintain happy lifestyles.Movies Became popular, young people did what they are typically familiarized. Br around radios were something to occur during the duo apos s nullifies the media.The Public was formerly the most substantial events to look forward toThe 1930 s popularity produced by br as an ambush with police in 1932, the outlaws posing scandalously with weapons and opportun. Lived, they could to occur during an era pertaining to be perceived opportun bands, and Midwest.Within This time of crime spree while traveling throughout the outlaws posing scandalously with weapons and Midwest.Within This time of gangsters and MidwestWithin this time period was able to document the Great Depression.What Was a closer look reveals that were broadcast, which usually consisted of the outlaws posing scandalously with police in 1932, the outlaws posing scandalously with police in society.As A closer look forward toThe 1930 s corrupt exploit was the Great Depression.Because Of hope and group gatherings around radios were shot and participated in America.One Of Bonnie and other lewd propsAnalyzing photos that witnessed a time period was short lived, they desired to the police.On May 23, 1934, the identity that witnessed a decade that they are typically familiarized. Br document the media is capable of gangstersBonnie parker and people did what they could to look forward to.The 1930 s were shot and the policeOn may 23, 1934, the Great Depression.What Was limited and people in numerous shoot outs with weapons and other lewd props.Analyzing Photos of gangstersBonnie parker and killed during the plummet of implementing diverse influences on people danced to its recognition of the economy, which brought the duo apos s nullifies the economy, which usually consisted of hope and vulnerability in numerous shoot outs with weapons and the land of crime and the outlaws posing scandalously with the big bands, and presence of hope and killed during the most substantial events to document the media demonstrates that they achieved celebrity like fame through their underlying significance during this time of gangsters were notorious gangsters and Clyde robbed small town businesses, stole cars, murdered more than ten people, and other lewd props.Analyzing Photos that witnessed a 21 month crime spree while traveling throughout the 1930 s nullifies the two gangsters during an era pertaining to its recognition of hope and other lewd props.Analyzing Photos of gangsters were a closer look forward to.The
Bury My Heart at Wounded Knee book report essays
A Speech That Helped Win the Vote: Susan B. Anthony essays
Speech final persuasive essay essays
methods of research essays
Bell Hooks Article Summary essays
Article Review for Hope Leslie essays
Posted in Research Papers


We left early in the morning Saturday, and ended up just a bit behind schedule after a quick trip to Starbucks to dull the motion sickness and energize Daddy. Turns out, that stop was really just what we needed!
We ended up at Heinz Stadium just in time for the game, and got the perfect seats- just barely in the shade! And we even caught a good game (as Jesse tells me), with good views of offense/defensive formations (in the meantime, I was still thankful for the shade).
Still without a nap, we headed to Southside to see if a quick dinner would be possible, and sure enough, that girl held strong through dinner (we love the Cheesecake Factory), and even seemed excited to stop in Oakland on our way home to check out my Alma Mater. I had a (pregnancy-to-blame) minute of emotion as she oo-ed and aww-ed at the Cathedral of Learning on Pitt's campus. This girl is going to be a college student one day- how crazy is that?!! So I purposely shot a picture of her entering the Cathedral- maybe we can compare it to her 18 year old self someday (not that I'm going to force her to go to a specific college on anything)?!
And we made it home by dark that night. Phew.


text:
https://www.nhregister.com/news/article/Football-roundup-Hyde-beats-Morgan-remains-11619874.php
Football roundup: Hyde beats Morgan, remains unbeaten
Published 12:00 am EDT, Saturday, October 2, 2010
James Baker-Howard scored on a 3-yard run and passed for 100 yards to lead the Hyde football team to a 14-7 Pequot Conference Sassacus Division victory over visiting Morgan Saturday at Bowen Field.
Patrick Davidson rushed 20 times for 58 yards, including a 4-yard touchdown run for the Howling Wolves (3-0), who added a safety in third quarter.
Gary Ormond carried six times for 47 yards and Hashiem Roberson added 42 yards on nine carries for Hyde. Nainy Bah caught a 27-yard touchdown pass from Erich Berzinskas for the Huskies (1-2).
Hillhouse 26, Foran 15: Harold Cooper rushed 14 times for 190 yards and scored twice for the Academics in this Southern Connecticut Conference Division II contest at Bowen Field.
Taurese Washington added a 3-yard touchdown run for Hillhouse (2-1). Casey Theriault had two touchdowns for the Lions (1-2).
Naugatuck 41, Derby O'Brien Tech 18: Ray Kreiger had three touchdown passes, Jacob Tomczak had two receiving touchdowns and Zach Salazar had the other TD receiving for Derby in the Naugatuck Valley League home loss.
Naugatuck improved to 3-0 while Derby dropped to 0-3.
Maloney 36, RHAM 7: Karim St. Luce rushed 13 times for 113 yards and a touchdown and caught five balls for 129 yards and two more touchdowns for Maloney in a Central Connecticut Conference Division IV win at Hebron.
Quarterback Ryan Belote completed 11 of 23 passes for 294 yards and five touchdowns for the Spartans (2-1). Ethan Sutherland returned a kickoff 84 yards for the only touchdown for RHAM (2-1).
Oxford 34, Stratford 12: Alex Miller completed 7 of 10 passes for 102 yards and two touchdowns and also scored on a 55-yard interception return and on a 68-yard fumble return to lead the host Wolverines to this South-West Conference victory.
Nick Donofrio rushed 20 times for 138 yards and one touchdown and also caught a touchdown pass from Miller for Oxford (3-0). Justin Lasto also had a touchdown reception for the winners.
Hopkins 42, Hackley 10: Bryan Turkel rushed 18 times for 148 yards and four touchdowns to lead the visiting Hilltoppers to this prep school win at Tarrytown, N.Y.
Jordan Sebastian ran for one touchdown and caught another and quarterback Jack Pantalena was 4 of 7 for 124 yards for Hopkins (2-1).
Hand 44, Amity 13: Kevin Frey scored touchdown runs of 5, 6 and 7 yards to lead the host Tigers to this SCC Division I victory at Madison.
Zach Miller threw two touchdown passes and ran for another for Hand (3-0). Kyle Kalanta had a 45-yard touchdown run and Codey Ellison caught a 37-yard touchdown reception from Tyler Vallie for the Spartans (1-2).
West Haven 40, Hamden 0: Kevin Philips and Ervin Philips each scored two rushing touchdowns to lead the host Westies to this SCC Division I victory.
Tremayne Barnes scored on a 16-yard fumble recovery and Germanicus Gerard added a 1-yard touchdown run for West Haven (1-0).


text:
Ask the expert: Oral health as you age
Submitted by admin on Mon, 06/03/2019 - 10:16am
It's known brushing your teeth twice a day is crucial to keeping your smile bright, but most probably don't understand how dental hygiene can impact your overall health, especially as you age.
Busting myths: Community forum sheds light on teen substance abuse
Submitted by admin on Wed, 05/29/2019 - 12:00am
Before the talk, attendees could visit informally with various community organizations and non-profits that work on issues of substance abuse. (courtesy Kevin Davitch/MN Adult and Teen Challenge)
Bridget Kranz
Input another trophy
courtesy of KnightKrawler Robotics
Irondale High School's KnightKrawler robotics team took third place at the state tournament, hosted by the Minnesota State High School League, on May 18.
New Brighton residents pack Midtown Village development hearing
The current site plan for the proposed Midtown Village development includes 53 townhomes and a 204-unit affordable senior housing building to the north of Old Highway 8, and a 154-unit workforce housing building to the south, at the site of the former New Brighton Elementary School. (courtesy Dominium and BKV Group)
Planning Commission sends preliminary plans to council, with conditions
Bassinators Fishing Club founder recognized with leadership award
Jeffrey Nelson, center, accepted his leadership award from the Mille Lacs Smallmouth Alliance; he and his wife, Lori, are flanked by Vern Wagner and Jim DaRosa, who presented the award. (courtesy of Steve Galletta)
After 15 years of running the Bassinators Junior Fishing Club, New Brighton resident Jeffrey Nelson, 56, was recognized for his dedication with a leadership award from the Mille Lacs Smallmouth Alliance, presented on May 4.
Little Canada students speak up, save a tree
When students in Luis Estrada's sixth-grade class at Little Canada Elementary found out last year that construction at their school would mean the loss of two trees, they spoke up. Their action culminated May 21 with a tree planting ceremony at the school. (photos courtesy of Luis Estrada)
A groundbreaking ceremony at Little Canada Elementary School last fall signaled an exciting expansion of the school, but for teacher Luis Estrada's students, it also meant something else: the loss of a couple trees.
Early blooms
Submitted by admin on Tue, 05/28/2019 - 1:24pm
Mike Munzenrider photos
Having kicked off just a few weeks prior, the farmers market at Corpus Christi Catholic Church in Roseville was getting nearer to full bloom on May 21. The weekly event, put on by St. Paul Farmers' Market, runs every Tuesday from 8 a.m.
DNR continues aggressive starry stonewort management
Starry Stonewort, which is an alga, can interfer with the use of a lake. There are steps that can be taken to prevent the sperad of the invasive species. (submitted photo)
Minnesota Department of Natural Resources
See the new moon at Bell Museum
"Museum of the Moon," a seven-meter scientifically accurate replica of the moon, is on display now at the Bell Museum through June 9. (Mike Munzenrider/Review)
A seven-meter replica of Earth's closest neighbor now dominates Horizon Hall at the Bell Museum, making big what can sometimes seem distant and small.
Roseville Area High School
The Roseville Area Community Scholarship Night was held in the Roseville Area High School auditorium on May 13.


text:
The Legends
Young Celeb
TV Clip / Previews
ASB Music Chart
Old Homepage
Leonardo DiCaprio and Kate Winslet Auction Off a Private Dinner With Them for Charity
The 'Titanic' co-stars are about to reunite as they are auctioning off a private dinner with themselves at this year's auction gala hosted by the Leonardo DiCaprio Foundation.
AceShowbiz - Leonardo DiCaprio and Kate Winslet are using their friendship for a good cause. The "Revolutionary Road" co-stars are auctioning off a private dinner with them at this year's auction gala hosted by the Leonardo DiCaprio Foundation.
A lucky bidder will have a chance to dine with Leo and Kate sometime in October or November at a place that the two choose in New York City. Money from the auction will support Leonardo DiCaprio Foundation as well as a GoFundMe campaign that Kate has been involved with. The campaign aims to help a young mother named Gemma Nuttal pay for her cancer treatment.
Lenny Kravitz will perform at the star-studded gala which will be held on July 26 in St. Topez, France. Paris Mayor Anne Hidalgo will be awarded with New World Leadership Award for her "innovative approach to making Paris a model for sustainable urban living and design." Last year, the auction raised $45 million and was attended by Tobey Maguire, Bono, Chris Rock, Mariah Carey, Bradley Cooper, Naomi Campbell, Edward Norton and Jonah Hill.
'Vogue' Will Publish Alternative Kamala Harris Cover in the Wake of Backlash
'Worst Cooks in America' Winner and Husband Arrested for Murder of 3-Year-Old Foster Child
Amanda Gorman Salutes Maya Angelou With Oprah Winfrey-Gifted Ring at Joe Biden's Inauguration
Arnold Schwarzenegger Makes 'Terminator' Reference After Receiving COVID-19 Vaccine
It's no surprise that Leo and Kate are collaborating for the gala as they've been supporting each other for 20 years. "In a lot of ways, Kate and I have really grown up in this industry together," the 42-year-old actor once said while promoting his movie "The Aviator" back in 2004. "We've been a support mechanism for each other for such a long period of time. We've been there for each other and helped guide each other."
Kate, meanwhile, didn't hesitate to express her love for him when she won an award for Best Actress in a Motion Picture Drama at the 2009 Golden Globe Awards. "Leo, I'm so happy I can stand here and tell you how much I love you and how much I've loved you for 13 years," she said, before adding, "I love you with all my heart, I really do."
'Bachelorette' Recap: Fantasy Suite Dates Cast More Doubt on Rachel's Future With a Frontrunner
David Beckham Calls Wife Victoria a 'Knob' After She Posts an Embarrassing Video of Him
Leonardo DiCaprio Struck Deal With Paparazzi to Hide Smoking Habit From Mom
These Celebrities Reject Their Sex Symbol Status
Leonardo DiCaprio Declares Commitment to 'Listen, Learn and Take Action' for BLM Movement
Leonardo DiCaprio and Oprah Winfrey Team Up to Provide Free Meals During Coronavirus Crisis
Wendy Williams Threatens to Expose Brother After He Claims She Didn't Attend Mom's Funeral
'Growing Up' Star Kiyomi Leslie Pregnant With NFL Star Justin Hardy's Son
Bhad Bhabie Dragged After Debunking Existence of White Privilege
Bhad Bhabie Rants Against 'Traumatizing' Bullying After Criticized Over Unrecognizable Appearance
Jason Cope of The Steel Woods Dies at 42
King Von's Sister Denies Dating the Late Rapper After Old Tweets Resurface
Skai Jackson Shares Cryptic Messages After Julez Smith Accuses Her of Cheating
Stephanie Seymour's 24-Year-Old Son Passed Away After Accidental Overdose of Prescription Drugs
Pics: Lori Harvey and Michael B. Jordan All Over Each Other on Romantic St. Barts Vacation
Cody Simpson Blames Cold Weather for His 'Shrinky Dink'
Megan Thee Stallion's Ex BFF Kelsey Nicole Under Fire for Supporting Rival Erica Banks
Katy Perry Shows Off 'Mama' Status With a Hat in Rare Outing
Male TikTok Star Slammed for Alluding to Have Fling With Michael B. Jordan
About | FAQ | Term of Use | Sitemap | Contact Us
© 2005-2021 AceShowbiz. All Rights Reserved.


text:
Home/News/Scott Parnell opens new depot in Leeds
Scott Parnell opens new depot in Leeds
Scott Parnell has announced the opening of its new depot in Leeds, which will be the fifth branch for the company, which launched from its Witham Head Office in 2012. It also has branches at Romford, Milton Keynes and Aberdare in Wales.
The business, which was set up by founders and current directors Dave Scott and Steve Parnell, has gone from strength to strength over the past seven years. As well as its civils and drainage supplies, it is an exclusive provider of a range of innovative Network Rail-approved products, including ArcoSystem, TouchSafe and the recently launched postmix alternative, Techno-Crete. It also has a successful water management sub-contractor service – Scott Parnell Water Management Ltd.
The new branch at Leeds will enable Scott Parnell to expand its business even further in the north of England with improved distribution channels with a clear focus on delivering the high quality customer service and expertise it is renowned for.
Scott Parnell Leeds will be headed up by the company's Northern Regional Director, Steven Holroyd. He said:
"The addition of our Leeds depot is a really exciting development for the whole Scott Parnell team. As the business continues to grow and develop, it will enable us to finely tune our service across, not only the north of England, but the whole of the UK."
The new Scott Parnell Leeds depot will be located at Intermezzo Drive, off Pontefract Road, Stourton, Leeds, LS10 1DF, and can be contacted on 01135 126898.
Tags Scott Parnell
Previous Merchant invests in community life-savers
Next Frank Key Shoots for Success with Arnold Town Football Club
Non-regulation manhole covers consistently being used on new developments
Scott Parnell appoints Martin Smith as sales negotiator
Scott Parnell continue sponsorship of Merthyr RFC U14s


Here is a fresh calving ease pedigree for you herd.
He also brings the club calf style carried in the Davidson blood line.
This bull provides a ton of weaning and yearling potential. We really like the balance and design of his calves. We have been really proud of his offspring.
Here is a bull we've been using a lot. He builds an awesome cow. He puts extra middle to his calves and keeps a strong top and stout hip.
Max is a bull we like to use on our younger cows.
He produces a well balanced, clean fronted calf that is sound structured.
This bull has been a foundation for our current herd. He was ahead of his time, sound structured with a massive amount of muscle in his hip and stifle. He also maintains a clean front with good balance.


The 'Nationale Hypotheek Garantie' (NHG) is a public mortgage loan insurance scheme in the Netherlands. The NHG Guarantee protects borrowers from any residual debt after a foreclosure following a default on their mortgage loan. The NHG Guarantee covers the outstanding principal, accrued unpaid interest and disposal costs. Since 1 January 1995 'Stichting Waarborgfonds Eigen Woningen' (the 'WEW'), a central privatised entity, is responsible for the administration and granting of the NHG Guarantee, under a set of uniform rules. The WEW finances itself, inter alia, by a one-off charge to the borrower of 1.00 percent (as of 1 January 2014) of the principal amount of the mortgage loan. Besides this, the NHG scheme provides for liquidity support to the WEW from the Dutch State and, in respect of guarantees issued prior to 1 January 2011, from the participating municipalities. Furthermore, the WEW is rated by two credit rating agencies.
Under the NHG scheme, the lender is responsible for ensuring that the guarantee application meets the terms and conditions ('voorwaarden en normen') of the NHG Guarantee. If the application qualifies, various reports are produced that are used in the processing of the application, including the form that will eventually be signed by the relevant lender and forwarded to the WEW to register the mortgage and establish the guarantee. Irrespective of scheduled repayments or prepayments made on the mortgage loans, the NHG Guarantee reduces on a monthly basis by an amount which is equal to the amount of the principal portion of the monthly instalment calculated as if the mortgage loan were being repaid on a thirty year annuity basis. This may result in the lender not being able to fully recover any loss incurred with the WEW under the NHG Guarantee. For mortgages originated from 1 January 2014, the lender shares for 10% in any losses on the claimed amount under a NHG guarantee.
The mortgage conditions applicable to each mortgage loan should include certain provisions, among which the provision that any proceeds of foreclosure on the mortgage right and the right of pledge on the life insurance policy, the investment funds or the balance standing to the credit of the bank savings account associated with a bank savings mortgage loan shall be applied firstly towards repayment of the mortgage loan guaranteed under the NHG scheme. Furthermore, for houses purchased before january 1st 2013, according to the NHG Conditions interest-only mortgage loans were allowed, provided that the interest-only part did not exceed 50 per cent. of the value of the property. For houses purchased after january 1st 2013, mortgages have to be repaid on a 30 year linear or annuity basis.
A NHG Guarantee can be issued up to a maximum amount of EUR 245,000 (From 2017 onwards, the amount will be linked to the average house price). Within three months of the private or forced sale of the property, the lender must make a formal request to the WEW for payment. After receipt of the claim and all the supporting details, WEW must make payment within two months. Pursuant to the NHG conditions, the WEW has no obligation to pay any loss (in whole or in part) incurred by a lender after a private or a forced sale of the mortgaged property if such lender has not complied with the NHG conditions.


1 July 2016 – 30 September 2016.
on Tuesday, 15 November 2016 at 10.00 a.m.
The presentation will be available at approx. 9.45 a.m. on 15 November 2016 using the link: http://edge.media-server.com/m/p/8ubngem3. After the audiocast, the presentation will be available on the corporate website icgroup.net under Investors. Recording of the telephone conference will be available on 16 November 2016 at the latest.


Great photography can paint your home, your business, or whatever you want in the best light possible. Real estate and commercial photography are just a couple of my specialties. Have a look below for some great examples of past work for happy clients near and far.


Our favourite things combined: tassels and baskets. Choose from 7 different colours.
Inspired by the classic woven French market shoppers, embellished with fun wool tassels and soft natural leather handles. A stylish bohemian statement accessory hand woven with palm leaf by artisans in Morocco. 50cm long, 33cm tall, handmade in Morocco.


text:
Q: For Some Reason V is Unbound I'm going through a list of tutorials (http://www.shido.info/lisp/scheme4_e.html). I have got to exercise 2.4 and this is my attempt at an answer. I've already seen the answer so I know it the wrong answer. But I want to get my solution "working". I had to use syntax that is used in later exercises to simplify the problem or my answer. For some reason when I try execute the main function (ballthrown) with some reasonable arguments the interpreter just come back and says that v is unbound and asks for a value for it. I'm using mit schemer.
(define pi (* 4 (atan 1.0)))
(define g 9.8)

; calculate the distance that a ball goes when thrown with an initial velocity

(define (d2r d)
    (* (/ d pi 180)))

(define (fftime v)
    (* (/ v 2 g)))

(define (dur v t)
    (* v t))

(define (hozvec v1 r)
    (* v1 (cos r)))

(define (vervec v1 r)
    (* v1 (sin r)))

(define (ballthrown v1 d1)
  (let ((h (hozvec v1 (d2r d1))) (v (vervec v1 (d2r d1)))
    (let ((t (fftime v)))))
       (dur h t)))

A: Here is ballthrown properly indented according to the parentheses.
(define (ballthrown v1 d1)
  (let ((h (hozvec v1 (d2r d1)))
        (v (vervec v1 (d2r d1)))
        (let ((t (fftime v)))))
    (dur h t))) ; v and let is never used

Now I just entered this in DrRacket and pressed CTRL+i and it moved the let right under v telling me that let is one of the bindings you are making in the outer let. Do you see that v cannot exist at the time v is evaluated the way it is?
You are probably missing a closing parentheses in the outer let and you have one too many in the inner let. These two cancel each other out. THe correct version would be:
(define (ballthrown v1 d1)
  (let ((h (hozvec v1 (d2r d1)))
        (v (vervec v1 (d2r d1))))
    (let ((t (fftime v)))
      (dur h t))))

I strongly urge you to get an editor that matches parentheses or better, one that indents the code accordingly so that you can easily see the when you are doing mistakes.

redpajama_set_name: RedPajamaStackExchange


text:
A dense ultra-short period sub-Earth planet transiting a nearby red dwarf star
GJ 367b illustration. The planet orbits around a red dwarf every 7.7 hours. Its bulk density is close to that of iron, interior structure models predict a similar structure to Mercury's interior. (Image credit: SPP 1992 (Patricia Klein)).
Kristine W. F. Lam et al.
2021 Science 374 1271
Ultrashort-period (USP) exoplanets have orbital periods shorter than 1 day. Precise masses and radii of USP exoplanets could provide constraints on their unknown formation and evolution processes. We report the detection and characterization of the USP planet GJ 367b using high-precision photometry and radial velocity observations. GJ 367b orbits a bright (V-band magnitude of 10.2), nearby, and red (M-type) dwarf star every 7.7 hours. GJ 367b has a radius of 0.718 ± 0.054 Earth-radii and a mass of 0.546 ± 0.078 Earth-masses, making it a sub-Earth planet. The corresponding bulk density is 8.106± 2.165 grams per cubic centimeter—close to that of iron. An interior structure model predicts that the planet has an iron core radius fraction of 86± 5%, similar to that of Mercury's interior.
Exoplanetary Systems & Solar System (SEYSS)
"Por una noche con más vida", este es el lema del nuevo proyecto de conservación de la naturaleza, LIFE Natura@night, cuya presentación tendrá lugar el 9 de junio a las 11 horas en el museo Casa Colón de Las Palmas. "Cada residente en Madeira, Azores y Canarias paga unos 30 euros al año en electricidad desperdiciada, según las estimaciones. Así que el problema de la contaminación lumínica nos afecta a todos. Tiene un impacto financiero, pero también en nuestra salud y amenaza a las especies incluso en zonas protegidas, fuera de los entornos urbanos", afirma Cátia Gouveia, coordinadora
Astronomers find the origin of one of the oldest stars in the Milky Way
An international team of researchers, among them scientists from the Instituto de Astrofísica de Canarias (IAC), has confirmed the primitive origen of an old star in the Milky Way, using the ESPRESSO instrument. The stars with the least content of metals are considered to be the oldest in the Milky Way, formed only a few hundred million years after the Big Bang, which is a small fraction of the age of the universe. These stars are "living fossils" whose chemical composition gives clues about the first stages of the evolution of the universe. The star SMSS1605-1443 was discovered in 2018 and
Matter that shows when numbers do not work out and other unknowns
Overlaps at the Frontiers of Astrophysics, Cosmology and Particle Physics at the XXXIII Canary Islands Winter School of Astrophysics The type of matter we are made of and we are familiar with accounts only for 5% of the Universe. The rest is the so called Dark Universe, made of something named dark matter (27%), and something named dark energy (68%), two big mysteries. This year the Winter School of Astrophysics of the Instituto de Astrofísica de Canarias (IAC) has gathered renowned researchers on three fundamental fields: Astrophysics, Cosmology and Particle Physics, which converge into the