Vie privée, vie publique sur France 3

LeLapin

13/04/2010 à 15:51

Ginette COUILLARD Camionneur en IVECO a tapoté du bout de ses petites
papattes :

Bonjour,

Gina Patterson
news:4bc44282$0$2966$

Pourquoi ? C'est plus compliqué encore que ce que vous proposez
quand il n'y a pas de content-type ?

Je préfère le charset-iso, je sais pas pourquoi... je trouve qu'en
UTF-8 ça donne bien. Vous trouvez pas ?

Le chaset-iso est encapsulé dans le Content-Type. Vous venez de
démontrer que vous êtes un bouffon. Bien à vous.

Juste comme ça, parce que nous on est pas très calés en charset-iso
encapsulé, ça veut dire quoi un charset-iso _encapsulé_** dans le
content-type ?

** Ce qui m'intéresse c'est _l'encapsulage_, hein.
Pas le charset-iso ni le content-type !

Ah tiens, quelqu'un a suivi le coup de l'"encapsulation" ;)
Elle va faire longtemps rire celle-là.

--
LeLapin

Ginette COUILLARD Camionneur en IVECO

13/04/2010 à 16:10

Bonjour,

LeLapin
news:hq1st4$1l0q$

| > ** Ce qui m'intéresse c'est _l'encapsulage_, hein.
| > Pas le charset-iso ni le content-type !

| Ah tiens, quelqu'un a suivi le coup de l'"encapsulation" ;)
| Elle va faire longtemps rire celle-là.

Attendons la réponse ?!? On ne sait pas tout, hein ?

On pourrait même être surpris de découvrir un bug caché (le
dernier ?) d'outlook express expliqué par Fucking Gina es-qualité.

--
Signature conforme placée sous un délimiteur "iso" au cas où des
phoques s'y intéresseraient.

rorodesbois

13/04/2010 à 16:16

"jean-marc Mannucci" a couché sur l'écran :

gné ?????

Ah ouais ! vous c'est du ISO-8859-1 bien françois ! encore un coup de
l'encapsulation Ginacalienne ça ! Z'avez raison, faut couper les trucs à
toute cette diaspora et ne plus alimenter leur UC en ventilation.

Gina Patterson

13/04/2010 à 16:50

Ginette COUILLARD Camionneur en IVECO a écrit le 13/04/2010 15:25:

** Ce qui m'intéresse c'est_l'encapsulage_, hein.
Pas le charset-iso ni le content-type !

On ne parle pas d'"encapsulage", mais de _décapsulage_. Dans notre cas,
on parle d'_encapsulation_.

Voici une définition de l'encapsulation :

Encapsulation
1/ Dans le contexte des télécommunications, méthode consistant à
regrouper des trames de données régies par des protocoles différents sur
un même réseau. Ainsi, des données, régies par le protocole SNA d'IBM,
pourront être mises à l'intérieur (d'où le terme encapsuler) de paquets
IP et transportées sur un réseau Internet.

Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

<http://www.ietf.org/rfc/rfc2045.txt>

5. 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. The
value in this field is called a media type.

HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.

The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.

In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data. Thus, a media 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 text, image, audio, and video should not contain embedded
information that is really of a different type. Such compound
formats should be represented using the "multipart" or "application"
types.

Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.

For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.

There are NO globally-meaningful parameters that apply to all media
types. Truly global mechanisms are best addressed, in the MIME
model, by the definition of additional Content-* header fields.

An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially opaque
as far as MIME processing is concerned. The remaining two are
composite types whose contents require additional handling by MIME
processors.

This set of top-level media types 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 a standards-track extension to this standard.
If another top-level 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.

Freed & Borenstein Standards Track [Page 11]

RFC 2045 Internet Message Bodies November 1996

5.1. Syntax of the Content-Type Header Field

In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:

content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>

x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>

parameter := attribute "=" value

attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>

tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values

Freed & Borenstein Standards Track [Page 12]

RFC 2045 Internet Message Bodies November 1996

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 -- it may not be
omitted from a Content-Type header field. As such, there are no
default subtypes.

The type, subtype, and parameter names are not case sensitive. For
example, TEXT, Text, and TeXt are all equivalent top-level media
types. Parameter values are normally case sensitive, but sometimes
are interpreted in a case-insensitive fashion, depending on the
intended use. (For example, multipart boundaries are case-sensitive,
but the "access-type" parameter for message/External-body is not
case-sensitive.)

Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms

Content-type: text/plain; charset=us-ascii (Plain text)

Content-type: text/plain; charset="us-ascii"

are completely equivalent.

Beyond this syntax, the only syntactic 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 media subtypes, then, is not
intended to be a mechanism for imposing restrictions, but simply a
mechanism for publicizing their definition and usage. There are,
therefore, two acceptable mechanisms for defining new media subtypes:

(1) Private values (starting with "X-") may be defined
bilaterally between two cooperating agents without
outside registration or standardization. Such values
cannot be registered or standardized.

(2) New standard values should be registered with IANA as
described in RFC 2048.

The second document in this set, RFC 2046, defines the initial set of
media types for MIME.

Freed & Borenstein Standards Track [Page 13]

RFC 2045 Internet Message Bodies November 1996

5.2. Content-Type Defaults

Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:

Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.

Ginette COUILLARD Camionneur en IVECO a écrit le 13/04/2010 15:25:

** Ce qui m'intéresse c'est_l'encapsulage_, hein.
Pas le charset-iso ni le content-type !

On ne parle pas d'"encapsulage", mais de _décapsulage_. Dans notre cas,
on parle d'_encapsulation_.

Voici une définition de l'encapsulation :

Encapsulation
1/ Dans le contexte des télécommunications, méthode consistant à
regrouper des trames de données régies par des protocoles différents sur
un même réseau. Ainsi, des données, régies par le protocole SNA d'IBM,
pourront être mises à l'intérieur (d'où le terme encapsuler) de paquets
IP et transportées sur un réseau Internet.

Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

<http://www.ietf.org/rfc/rfc2045.txt>

5. 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. The
value in this field is called a media type.

HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.

The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.

In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data. Thus, a media 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 text, image, audio, and video should not contain embedded
information that is really of a different type. Such compound
formats should be represented using the "multipart" or "application"
types.

Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.

For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.

There are NO globally-meaningful parameters that apply to all media
types. Truly global mechanisms are best addressed, in the MIME
model, by the definition of additional Content-* header fields.

An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially opaque
as far as MIME processing is concerned. The remaining two are
composite types whose contents require additional handling by MIME
processors.

This set of top-level media types 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 a standards-track extension to this standard.
If another top-level 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.

Freed & Borenstein Standards Track [Page 11]

RFC 2045 Internet Message Bodies November 1996

5.1. Syntax of the Content-Type Header Field

In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:

content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>

x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>

parameter := attribute "=" value

attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>

tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values

Freed & Borenstein Standards Track [Page 12]

RFC 2045 Internet Message Bodies November 1996

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 -- it may not be
omitted from a Content-Type header field. As such, there are no
default subtypes.

The type, subtype, and parameter names are not case sensitive. For
example, TEXT, Text, and TeXt are all equivalent top-level media
types. Parameter values are normally case sensitive, but sometimes
are interpreted in a case-insensitive fashion, depending on the
intended use. (For example, multipart boundaries are case-sensitive,
but the "access-type" parameter for message/External-body is not
case-sensitive.)

Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms

Content-type: text/plain; charset=us-ascii (Plain text)

Content-type: text/plain; charset="us-ascii"

are completely equivalent.

Beyond this syntax, the only syntactic 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 media subtypes, then, is not
intended to be a mechanism for imposing restrictions, but simply a
mechanism for publicizing their definition and usage. There are,
therefore, two acceptable mechanisms for defining new media subtypes:

(1) Private values (starting with "X-") may be defined
bilaterally between two cooperating agents without
outside registration or standardization. Such values
cannot be registered or standardized.

(2) New standard values should be registered with IANA as
described in RFC 2048.

The second document in this set, RFC 2046, defines the initial set of
media types for MIME.

Freed & Borenstein Standards Track [Page 13]

RFC 2045 Internet Message Bodies November 1996

5.2. Content-Type Defaults

Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:

Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.

Vous avez filtré cet utilisateur ! Consultez son message

Ginette COUILLARD Camionneur en IVECO a écrit le 13/04/2010 15:25:

** Ce qui m'intéresse c'est_l'encapsulage_, hein.
Pas le charset-iso ni le content-type !

On ne parle pas d'"encapsulage", mais de _décapsulage_. Dans notre cas,
on parle d'_encapsulation_.

Voici une définition de l'encapsulation :

Encapsulation
1/ Dans le contexte des télécommunications, méthode consistant à
regrouper des trames de données régies par des protocoles différents sur
un même réseau. Ainsi, des données, régies par le protocole SNA d'IBM,
pourront être mises à l'intérieur (d'où le terme encapsuler) de paquets
IP et transportées sur un réseau Internet.

Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

<http://www.ietf.org/rfc/rfc2045.txt>

5. 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. The
value in this field is called a media type.

HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.

The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.

In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data. Thus, a media 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 text, image, audio, and video should not contain embedded
information that is really of a different type. Such compound
formats should be represented using the "multipart" or "application"
types.

Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.

For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.

There are NO globally-meaningful parameters that apply to all media
types. Truly global mechanisms are best addressed, in the MIME
model, by the definition of additional Content-* header fields.

An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially opaque
as far as MIME processing is concerned. The remaining two are
composite types whose contents require additional handling by MIME
processors.

This set of top-level media types 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 a standards-track extension to this standard.
If another top-level 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.

Freed & Borenstein Standards Track [Page 11]

RFC 2045 Internet Message Bodies November 1996

5.1. Syntax of the Content-Type Header Field

In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:

content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>

x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>

parameter := attribute "=" value

attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>

tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values

Freed & Borenstein Standards Track [Page 12]

RFC 2045 Internet Message Bodies November 1996

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 -- it may not be
omitted from a Content-Type header field. As such, there are no
default subtypes.

The type, subtype, and parameter names are not case sensitive. For
example, TEXT, Text, and TeXt are all equivalent top-level media
types. Parameter values are normally case sensitive, but sometimes
are interpreted in a case-insensitive fashion, depending on the
intended use. (For example, multipart boundaries are case-sensitive,
but the "access-type" parameter for message/External-body is not
case-sensitive.)

Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms

Content-type: text/plain; charset=us-ascii (Plain text)

Content-type: text/plain; charset="us-ascii"

are completely equivalent.

Beyond this syntax, the only syntactic 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 media subtypes, then, is not
intended to be a mechanism for imposing restrictions, but simply a
mechanism for publicizing their definition and usage. There are,
therefore, two acceptable mechanisms for defining new media subtypes:

(1) Private values (starting with "X-") may be defined
bilaterally between two cooperating agents without
outside registration or standardization. Such values
cannot be registered or standardized.

(2) New standard values should be registered with IANA as
described in RFC 2048.

The second document in this set, RFC 2046, defines the initial set of
media types for MIME.

Freed & Borenstein Standards Track [Page 13]

RFC 2045 Internet Message Bodies November 1996

5.2. Content-Type Defaults

Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:

Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.

Ginette COUILLARD Camionneur en IVECO

13/04/2010 à 18:10

Bonjour,

Gina Patterson
news:4bc48481$0$28934$

| Voici une définition de l'encapsulation :

| Encapsulation
| 1/ Dans le contexte des télécommunications, méthode consistant
| à regrouper des trames de données régies par des protocoles différents
| sur un même réseau. Ainsi, des données, régies par le protocole SNA
| d'IBM, pourront être mises à l'intérieur (d'où le terme encapsuler)
| de paquets IP et transportées sur un réseau Internet.

Je sais ce qu'est "l'encapsulation" qui permet, entre autres, (lorsque
l'implémentation du logiciel de transmission a été réalisée par un
patterson de seconde zone) de véhiculer dans des paquets "mal ficelés"
du code malveillant mais l'encapsulation n'a...

...RIEN A VOIR AVEC LE CONTENT-TYPE !!!

Un paquet c'est : un identifiant du paquet + un certain nombre de bits
permettant d'acheminer le paquet au bon endroit + un certain nombre de
bits de données + un ou des bit(s) de controle de "qualité" du paquet.

Et ce quel que soit ce que l'on doit faire voyager ; c'est un format
de transmission qui se fout de ce qu'il contient précisément sauf
de la parfaite concordance entre ce qui est parti et arrivé.

Autrement dit si au départ grace à la nullité du développeur de
l'application de transfert on insère des trucs malveillants ce sera
transparent pour le protocole de transfert et on pourra faire plein
de choses dans la machine distante.

| Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

Je sais ce qu'est le Content-Type sombre cloche.

Et je vous conseille de lire les en-têtes de l'article auquel vous répondiez
juste pour voir "l'encapsulation" que l'on "peut y faire" _mais qui n'a rien
à voir_ avec ce pourquoi on met dans le Content-Type :

==> _une description_ de ce qui va suivre dans le reste de l'article mais
qui n'est en rien critique, la preuve :

Allez, juste pour le plaisir je vous copicolle le Content-Type de l'article
précité et qui malgré son caractère hautement normalisé ne vous a pas
empêché de le lire et, hélas, d'y répondre n'importe quoi en tapant dans
gogole ou assimilé.

Et pour le fun, juste en dessous, le Content-Type de mon article de réponse
à lapinus vulgaros garennovichsky.

[Insère]

Message-ID: <news:

Content-Type: text/plain;
charsockettemontanteblanche="iso-9999-6666-cestbientotmonanniversaire"

Message-ID: <news:

Content-Type: text/plain; charset="patterson sonne sonne sonne"

[Fin d'insère]

Je vous laisse découvrir celui de cet article.

--

Bonjour,

Gina Patterson
news:4bc48481$0$28934$ba4acef3@reader.news.orange.fr

| Voici une définition de l'encapsulation :

| Encapsulation
| 1/ Dans le contexte des télécommunications, méthode consistant
| à regrouper des trames de données régies par des protocoles différents
| sur un même réseau. Ainsi, des données, régies par le protocole SNA
| d'IBM, pourront être mises à l'intérieur (d'où le terme encapsuler)
| de paquets IP et transportées sur un réseau Internet.

Je sais ce qu'est "l'encapsulation" qui permet, entre autres, (lorsque
l'implémentation du logiciel de transmission a été réalisée par un
patterson de seconde zone) de véhiculer dans des paquets "mal ficelés"
du code malveillant mais l'encapsulation n'a...

...RIEN A VOIR AVEC LE CONTENT-TYPE !!!

Un paquet c'est : un identifiant du paquet + un certain nombre de bits
permettant d'acheminer le paquet au bon endroit + un certain nombre de
bits de données + un ou des bit(s) de controle de "qualité" du paquet.

Et ce quel que soit ce que l'on doit faire voyager ; c'est un format
de transmission qui se fout de ce qu'il contient précisément sauf
de la parfaite concordance entre ce qui est parti et arrivé.

Autrement dit si au départ grace à la nullité du développeur de
l'application de transfert on insère des trucs malveillants ce sera
transparent pour le protocole de transfert et on pourra faire plein
de choses dans la machine distante.

| Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

Je sais ce qu'est le Content-Type sombre cloche.

Et je vous conseille de lire les en-têtes de l'article auquel vous répondiez
juste pour voir "l'encapsulation" que l'on "peut y faire" _mais qui n'a rien
à voir_ avec ce pourquoi on met dans le Content-Type :

==> _une description_ de ce qui va suivre dans le reste de l'article mais
qui n'est en rien critique, la preuve :

Allez, juste pour le plaisir je vous copicolle le Content-Type de l'article
précité et qui malgré son caractère hautement normalisé ne vous a pas
empêché de le lire et, hélas, d'y répondre n'importe quoi en tapant dans
gogole ou assimilé.

Et pour le fun, juste en dessous, le Content-Type de mon article de réponse
à lapinus vulgaros garennovichsky.

[Insère]

Message-ID: <news:hq21u5.hq21u5.18os.1@2010.hba0eae37.1304152500>

Content-Type: text/plain;
charsockettemontanteblanche="iso-9999-6666-cestbientotmonanniversaire"

Message-ID: <news:hq2536.hq2536.1avk.1@2010.hfb33eae1.1304161000>

Content-Type: text/plain; charset="patterson sonne sonne sonne"

[Fin d'insère]

Je vous laisse découvrir celui de cet article.

--

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Gina Patterson
news:4bc48481$0$28934$

| Voici une définition de l'encapsulation :

| Encapsulation
| 1/ Dans le contexte des télécommunications, méthode consistant
| à regrouper des trames de données régies par des protocoles différents
| sur un même réseau. Ainsi, des données, régies par le protocole SNA
| d'IBM, pourront être mises à l'intérieur (d'où le terme encapsuler)
| de paquets IP et transportées sur un réseau Internet.

Je sais ce qu'est "l'encapsulation" qui permet, entre autres, (lorsque
l'implémentation du logiciel de transmission a été réalisée par un
patterson de seconde zone) de véhiculer dans des paquets "mal ficelés"
du code malveillant mais l'encapsulation n'a...

...RIEN A VOIR AVEC LE CONTENT-TYPE !!!

Un paquet c'est : un identifiant du paquet + un certain nombre de bits
permettant d'acheminer le paquet au bon endroit + un certain nombre de
bits de données + un ou des bit(s) de controle de "qualité" du paquet.

Et ce quel que soit ce que l'on doit faire voyager ; c'est un format
de transmission qui se fout de ce qu'il contient précisément sauf
de la parfaite concordance entre ce qui est parti et arrivé.

Autrement dit si au départ grace à la nullité du développeur de
l'application de transfert on insère des trucs malveillants ce sera
transparent pour le protocole de transfert et on pourra faire plein
de choses dans la machine distante.

| Voilà qui vous expliquera l'encapsulation au sein du Content-Type :

Je sais ce qu'est le Content-Type sombre cloche.

Et je vous conseille de lire les en-têtes de l'article auquel vous répondiez
juste pour voir "l'encapsulation" que l'on "peut y faire" _mais qui n'a rien
à voir_ avec ce pourquoi on met dans le Content-Type :

==> _une description_ de ce qui va suivre dans le reste de l'article mais
qui n'est en rien critique, la preuve :

Allez, juste pour le plaisir je vous copicolle le Content-Type de l'article
précité et qui malgré son caractère hautement normalisé ne vous a pas
empêché de le lire et, hélas, d'y répondre n'importe quoi en tapant dans
gogole ou assimilé.

Et pour le fun, juste en dessous, le Content-Type de mon article de réponse
à lapinus vulgaros garennovichsky.

[Insère]

Message-ID: <news:

Content-Type: text/plain;
charsockettemontanteblanche="iso-9999-6666-cestbientotmonanniversaire"

Message-ID: <news:

Content-Type: text/plain; charset="patterson sonne sonne sonne"

[Fin d'insère]

Je vous laisse découvrir celui de cet article.

--

LeLapin

13/04/2010 à 18:16

Gina Patterson a tapoté du bout de ses petites papattes :

Ginette COUILLARD Camionneur en IVECO a écrit le 13/04/2010 15:25:

** Ce qui m'intéresse c'est_l'encapsulage_, hein.
Pas le charset-iso ni le content-type !

On ne parle pas d'"encapsulage", mais de _décapsulage_. Dans notre cas, on
parle d'_encapsulation_.

Voici une définition de l'encapsulation :

<snip>

Cool, alors si tu as (enfin) lu ce qu'est l'encapsulation, tu vas
arrêter de dire qu'on encapsule une valeur dans un paramètre, hein ? :D
Genre "Le chaset-iso est encapsulé dans le Content-Type.", qui a quand
même été mon meilleur fou-rire du jour... ;)
(c'est con, avec ma côte cassée, ça fait mal...)

--
LeLapin

Gina Patterson

13/04/2010 à 18:50

Ginette COUILLARD Camionneur en IVECO a écrit le 13/04/2010 18:10:

Je sais ce qu'est "l'encapsulation"

Mais bien sûr : et vous parlez d'"_encapsulage_" après que j'ai dit
"encapsuler": vous êtes très très risible. Comme tout ce que vous écrivez.

Je sais ce qu'est le Content-Type

Oui, je vous lai appris.

sombre cloche.

Voyons voir ...

[Insère]
[Fin d'insère]

Ah oui, effectivement. Après "encaspsulage", on a "insère", "début,
milieu, fin d'insère" : _EXCELLENT_. Vous êtes une cloche illuminée.
Bien à vous.

P.S : évitez de buguer et de rajouter votre email en destinataire.

Gina Patterson

13/04/2010 à 19:02

LeLapin a écrit le 13/04/2010 18:16:

Genre "Le chaset-iso est encapsulé dans le Content-Type.", qui a quand
même été mon meilleur fou-rire du jour... ;)

Tenez, un nouvelle couche :
http://www.commentcamarche.net/contents/poo/encapsul.php3

(c'est con, avec ma côte cassée, ça fait mal...)

Dommage, Mr Guillon aurait parlé de vous demain matin sur France Inter.

LeLapin

13/04/2010 à 19:06

Gina Patterson a tapoté du bout de ses petites papattes :

LeLapin a écrit le 13/04/2010 18:16:

Genre "Le chaset-iso est encapsulé dans le Content-Type.", qui a quand
même été mon meilleur fou-rire du jour... ;)

Tenez, un nouvelle couche :
http://www.commentcamarche.net/contents/poo/encapsul.php3

(c'est con, avec ma côte cassée, ça fait mal...)

Dommage, Mr Guillon aurait parlé de vous demain matin sur France Inter.

Ne cherche pas à te raccrocher à des branches bien fragiles, tu as
démontré que tu ne savais absolument pas ce qu'est l'encapsulation en
informatique. Tu es risible et ridicule. Va faire ton show ailleurs.
Sur le Minitel par exemple, il y a encore quelques débiles qui en font.

--
LeLapin

Gina Patterson

13/04/2010 à 19:13

LeLapin a écrit le 13/04/2010 19:06:

tu as démontré que tu ne savais absolument pas ce qu'est l'encapsulation en informatique.

Bravo Mr LeLapin : vous démontrez que vous brassez des concepts que vous
ne connaissez pas : l'encapsulation "en informatique" n'existe pas.

Vie privée, vie publique sur France 3

10 réponses

Veuillez sélectionner un problème