Sur mon IBook G4 flambant neuf, avec un 10.3 client pré installé dessus,
j'aimerais savoir s'il est possible de formater en "HFS+ sensible à la
casse", celui qui distingue les majuscules des minuscules dans les noms
de fichiers.
Le 6/12/04 0:04, dans , « DINH Viêt Hoà » a écrit :
La partie UFS de Mac OS X doit toujours être du 4.4BSD sans aucun des ajouts des *BSD récents.
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
D'autres programmes qu'Entourage font le même traitement sur les mots / phrases. Un décodeur doit être souple pour ne pas bloquer sur des détails de ce type.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 6/12/04 0:04, dans <etPan.41b39415.4698efde.2236@utopia>, « DINH Viêt
Hoà » <dinh.viet.hoa@free.fr> a écrit :
La partie UFS de Mac OS X doit toujours être du 4.4BSD sans aucun des ajouts
des *BSD récents.
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un
encodage partiels sur les lettres à encoder.
D'autres programmes qu'Entourage font le même traitement sur les mots /
phrases. Un décodeur doit être souple pour ne pas bloquer sur des détails de
ce type.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 6/12/04 0:04, dans , « DINH Viêt Hoà » a écrit :
La partie UFS de Mac OS X doit toujours être du 4.4BSD sans aucun des ajouts des *BSD récents.
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
D'autres programmes qu'Entourage font le même traitement sur les mots / phrases. Un décodeur doit être souple pour ne pas bloquer sur des détails de ce type.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
DINH Viêt Hoà
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
Que veux-tu dire par "qu'il traite spécialement" ?
Tout ce que je vois, c'est qu'il n'est pas conforme à la RFC.
Il y a plusieurs façon d'interpréter la façon dont entourage encode les choses si on est souple.
garbage in, garbage out.
-- DINH V. Hoa,
"Il y a anguille sous roche"
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
Que veux-tu dire par "qu'il traite spécialement" ?
Tout ce que je vois, c'est qu'il n'est pas conforme à la RFC.
Il y a plusieurs façon d'interpréter la façon dont entourage encode
les choses si on est souple.
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu à des interprétations possibles très bizarres. Mais lorsqu'on encode chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais donne lieu à des interprétation différentes possibles lorsqu'on essaie de décoder.
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de l'IETF.
-- DINH V. Hoa,
"Il y a anguille sous roche"
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
C'est juste les blancs qu'il traite spécialement.
Que veux-tu dire par "qu'il traite spécialement" ?
Tout ce que je vois, c'est qu'il n'est pas conforme à la RFC.
Il y a plusieurs façon d'interpréter la façon dont entourage encode
les choses si on est souple.
garbage in, garbage out.
en relisant la RFC 2822 et RFC 2047 de près, effectivement, il semble
que ce soit possible :
phrase = 1*( encoded-word / word )
word = atom / quoted-string
atom = [CFWS] 1*atext [CFWS]
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu
à des interprétations possibles très bizarres. Mais lorsqu'on encode
chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la
grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais
donne lieu à des interprétation différentes possibles lorsqu'on essaie
de décoder.
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de
l'IETF.
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu à des interprétations possibles très bizarres. Mais lorsqu'on encode chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais donne lieu à des interprétation différentes possibles lorsqu'on essaie de décoder.
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de l'IETF.
-- DINH V. Hoa,
"Il y a anguille sous roche"
Laurent Wacrenier
DINH Viêt Hoà écrit:
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'.
Je pense que les autres lecteurs de news, du coup, doivent essayer de faire un workaround pour Entourage et essayer de décoder ça comme ils peuvent. C'est effectivement un cas où le respect des normes par Microsoft est approximatif. Ce genre de dérive est heureusement assez rare.
Je pense plutôt qu'ils ne se prennent pas la tête et décodent les "pharse", "text", etc. sans les découper en atomes et les recomposer.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un
encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a
'phrase' MUST be separated from any adjacent 'word', 'text' or
'special' by 'linear-white-space'.
Je pense que les autres lecteurs de news, du coup, doivent essayer de
faire un workaround pour Entourage et essayer de décoder ça comme ils
peuvent. C'est effectivement un cas où le respect des normes par
Microsoft est approximatif. Ce genre de dérive est heureusement assez
rare.
Je pense plutôt qu'ils ne se prennent pas la tête et décodent les
"pharse", "text", etc. sans les découper en atomes et les recomposer.
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'.
Je pense que les autres lecteurs de news, du coup, doivent essayer de faire un workaround pour Entourage et essayer de décoder ça comme ils peuvent. C'est effectivement un cas où le respect des normes par Microsoft est approximatif. Ce genre de dérive est heureusement assez rare.
Je pense plutôt qu'ils ne se prennent pas la tête et décodent les "pharse", "text", etc. sans les découper en atomes et les recomposer.
Eric Lévénez
Le 6/12/04 9:26, dans , « DINH Viêt Hoà » a écrit :
en relisant la RFC 2822 et RFC 2047 de près, effectivement, il semble que ce soit possible :
phrase = 1*( encoded-word / word )
word = atom / quoted-string atom = [CFWS] 1*atext [CFWS]
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu à des interprétations possibles très bizarres. Mais lorsqu'on encode chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais donne lieu à des interprétation différentes possibles lorsqu'on essaie de décoder.
Pour info c'est Entourage 2004 qui fait cela, Entourage X était plus conforme (encodage par mot). Et c'est pour cela que maintenant j'écris "Eric Lévénez" et non plus "Éric Lévénez".
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de l'IETF.
Je en sais pas. Pour savoir si ce que dit le RFC est correcte à 100 % ou à 98 % (dans sa formulation par rapport à son esprit) par rapport à ce que fond les mailers, il faudrait passer du temps à décortiquer chaque mot et chaque syllabe du RFC, et là je n'ai pas le courage.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 6/12/04 9:26, dans <etPan.41b417a9.6888f3cf.2236@utopia>, « DINH Viêt
Hoà » <dinh.viet.hoa@free.fr> a écrit :
en relisant la RFC 2822 et RFC 2047 de près, effectivement, il semble
que ce soit possible :
phrase = 1*( encoded-word / word )
word = atom / quoted-string
atom = [CFWS] 1*atext [CFWS]
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu
à des interprétations possibles très bizarres. Mais lorsqu'on encode
chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la
grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais
donne lieu à des interprétation différentes possibles lorsqu'on essaie
de décoder.
Pour info c'est Entourage 2004 qui fait cela, Entourage X était plus
conforme (encodage par mot). Et c'est pour cela que maintenant j'écris "Eric
Lévénez" et non plus "Éric Lévénez".
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de
l'IETF.
Je en sais pas. Pour savoir si ce que dit le RFC est correcte à 100 % ou à
98 % (dans sa formulation par rapport à son esprit) par rapport à ce que
fond les mailers, il faudrait passer du temps à décortiquer chaque mot et
chaque syllabe du RFC, et là je n'ai pas le courage.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Les espaces entre les "atom" ne sont pas obligatoires, ce qui donne lieu à des interprétations possibles très bizarres. Mais lorsqu'on encode chaque "atom" séparé par des espaces, cela lève toute ambiguïté de la grammaire.
Entourage est donc conforme à la grammaire au niveau de l'encodage mais donne lieu à des interprétation différentes possibles lorsqu'on essaie de décoder.
Pour info c'est Entourage 2004 qui fait cela, Entourage X était plus conforme (encodage par mot). Et c'est pour cela que maintenant j'écris "Eric Lévénez" et non plus "Éric Lévénez".
Peux-tu confirmer ceci ? J'en toucherai peut-être mot aux gens de l'IETF.
Je en sais pas. Pour savoir si ce que dit le RFC est correcte à 100 % ou à 98 % (dans sa formulation par rapport à son esprit) par rapport à ce que fond les mailers, il faudrait passer du temps à décortiquer chaque mot et chaque syllabe du RFC, et là je n'ai pas le courage.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
DINH Viêt Hoà
DINH Viêt Hoà écrit:
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'.
ok, il y a donc bien un bug du côté d'entourage.
-- DINH V. Hoa,
"Il y a anguille sous roche"
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un
encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a
'phrase' MUST be separated from any adjacent 'word', 'text' or
'special' by 'linear-white-space'.
c'est plutôt Entourage qui encode très bizarrement les en-têtes.
RFC 2047 définit plutôt un encodage intégral des mots plutôt qu'un encodage partiels sur les lettres à encoder.
Plus précisément, dans le cas de From :
An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'.
ok, il y a donc bien un bug du côté d'entourage.
-- DINH V. Hoa,
"Il y a anguille sous roche"
Grrrr
On Mon, 06 Dec 2004 07:41:53 +0100, Eric L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
Le 5/12/04 22:48, dans , « Grrrr » a écrit :
On Sun, 05 Dec 2004 20:34:56 +0100, Eric L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
[...]
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
Non, il n'y a que l'ASCII qui soit valide dans les entêtes. Pan a raison.
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ? " This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. " Aucune mention de usenet.... Donc ça n'a rien à voir... S'il y a une extension pour supporter celà dans usenet (c'est possible), en tout cas, ce n'est pas ça.
On Mon, 06 Dec 2004 07:41:53 +0100, Eric
L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
Le 5/12/04 22:48, dans <pan.2004.12.05.21.48.46.179133@Grrr.org>, « Grrrr »
<Grrr@Grrr.org> a écrit :
On Sun, 05 Dec 2004 20:34:56 +0100, Eric
L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
[...]
PS: C'est etPan qui se plante dans la gestion des accents dans les
en-têtes?
Non, il n'y a que l'ASCII qui soit valide dans les entêtes. Pan a raison.
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
" This particular document is the third document in the series. It
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields.
"
Aucune mention de usenet.... Donc ça n'a rien à voir...
S'il y a une extension pour supporter celà dans usenet (c'est possible),
en tout cas, ce n'est pas ça.
On Mon, 06 Dec 2004 07:41:53 +0100, Eric L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
Le 5/12/04 22:48, dans , « Grrrr » a écrit :
On Sun, 05 Dec 2004 20:34:56 +0100, Eric L=?ISO-8859-1?B?6Q==?=v=?ISO-8859-1?B?6Q==?=nez wrote:
[...]
PS: C'est etPan qui se plante dans la gestion des accents dans les en-têtes?
Non, il n'y a que l'ASCII qui soit valide dans les entêtes. Pan a raison.
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ? " This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. " Aucune mention de usenet.... Donc ça n'a rien à voir... S'il y a une extension pour supporter celà dans usenet (c'est possible), en tout cas, ce n'est pas ça.
DINH Viêt Hoà
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ? " This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. " Aucune mention de usenet.... Donc ça n'a rien à voir... S'il y a une extension pour supporter celà dans usenet (c'est possible), en tout cas, ce n'est pas ça.
Dans la vraie vie où les gens écrivent leur articles avec des accents, les lecteurs de news utilisent RFC 2047 pour encoder les sujets.
-- DINH V. Hoa,
"Il y a anguille sous roche"
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
" This particular document is the third document in the series. It
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields.
"
Aucune mention de usenet.... Donc ça n'a rien à voir...
S'il y a une extension pour supporter celà dans usenet (c'est possible),
en tout cas, ce n'est pas ça.
Dans la vraie vie où les gens écrivent leur articles avec des accents,
les lecteurs de news utilisent RFC 2047 pour encoder les sujets.
Usenet, c'est du mail ? C'est nouveau ? " This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. " Aucune mention de usenet.... Donc ça n'a rien à voir... S'il y a une extension pour supporter celà dans usenet (c'est possible), en tout cas, ce n'est pas ça.
Dans la vraie vie où les gens écrivent leur articles avec des accents, les lecteurs de news utilisent RFC 2047 pour encoder les sujets.
-- DINH V. Hoa,
"Il y a anguille sous roche"
Laurent Wacrenier
Grrrr écrit:
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that all USENET news messages must be formatted as valid Internet mail messages, according to the Internet standard RFC-822. The USENET News standard is more restrictive than the Internet standard, placing additional requirements on each message and forbidding use of certain Internet features. However, it should always be possible to use a tool expecting an Internet message to process a news message. In any situation where this standard conflicts with the Internet standard, RFC-822 should be considered correct and this standard in error.
C'était déjà là dans la RFC 850 datée de 1983.
Grrrr <Grrr@Grrr.org> écrit:
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that
all USENET news messages must be formatted as valid Internet mail
messages, according to the Internet standard RFC-822. The USENET
News standard is more restrictive than the Internet standard,
placing additional requirements on each message and forbidding use
of certain Internet features. However, it should always be possible
to use a tool expecting an Internet message to process a news
message. In any situation where this standard conflicts with the
Internet standard, RFC-822 should be considered correct and this
standard in error.
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that all USENET news messages must be formatted as valid Internet mail messages, according to the Internet standard RFC-822. The USENET News standard is more restrictive than the Internet standard, placing additional requirements on each message and forbidding use of certain Internet features. However, it should always be possible to use a tool expecting an Internet message to process a news message. In any situation where this standard conflicts with the Internet standard, RFC-822 should be considered correct and this standard in error.
C'était déjà là dans la RFC 850 datée de 1983.
Grrrr
On Mon, 06 Dec 2004 14:34:48 +0000, Laurent Wacrenier wrote:
Grrrr écrit:
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that all USENET news messages must be formatted as valid Internet mail messages, according to the Internet standard RFC-822. The USENET News standard is more restrictive than the Internet standard, placing additional requirements on each message and forbidding use of certain Internet features. However, it should always be possible to use a tool expecting an Internet message to process a news message. In any situation where this standard conflicts with the Internet standard, RFC-822 should be considered correct and this standard in error.
C'était déjà là dans la RFC 850 datée de 1983.
Et c'est bien marqué "basé sur la RFC822" qui n'authorise que l'ASCII. Et elle n'est pas indiqué obsolete. D'un autre coté, je prends les "Usenet best practice" (mai 2004). Ca commence fort: " Here it shold be noted that what is acceptable in Email (which is a one-to-few communication where the author can be expected to be aware of the capabilities and preferences of his correspondents) may not be acceptable in Netnews (which is a one-to-many communication directed at an unseen and unknown audience). Much grief has arisen in the past from poorly designed agents which tried to imppose onto Usenet defaults and practices which were perfectly appropriate for Email. " Ce qui veut bien dire que les news n'acceptent pas tout ce que le mail accepte mais sont par contre lisibles en tant que mail.
" Subject-headers are for humans to read, and the most that user agents should do is to filter them as directed by their human readers. If some enhancement to Netnews requires support within the headers, then the proper procedure is to invent a new header for the purpose, or to adapt an existing header (supposing it had the capability to support such adaptations). " Ce qui veut dire que si on veut faire des extensions au header "Subject" il faut employer un autre header non standard. Le seul endroit ou on parle de charset, de MIME dans ce document est pour la construction et l'interprétation du body, jamais pour les headers.
Le dernier draft disponible sur les news (qui date de septembre 2004 mais n'est pas publié en tant que RFC et encore moins approuvé) parle lui, effectivement de type MIME dans les headers de news: " The character set for headers is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2045] and [RFC2231]. " Le problème, c'est qu'il n'est pas approuvé:
"Usenet Format Working Group C. Lindsey Internet-Draft University of Manchester Obsoletes: 1036 (if approved) K. Murchison Expires: March 15, 2005 Oceana Matrix Ltd. D. Kohn Skymoon Ventures September 14, 2004 "
Donc, dans l'intervalle, ça reste interdit puisque la référence est encore la RFC 1036 qui se base sur la 822 qui n'authorise que l'ASCII dans les headers. Cf: <http://www.karlsruhe.org/rfc/draft-ietf-usefor-usefor-01.txt>
j'ai profité de cette lecture pour corriger mon profil en rajoutant .invalid à la fin de mon addresse, comme spécifié (comme quoi, c'est utile de lire les RFC et drafts...).
On Mon, 06 Dec 2004 14:34:48 +0000, Laurent Wacrenier wrote:
Grrrr <Grrr@Grrr.org> écrit:
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that
all USENET news messages must be formatted as valid Internet mail
messages, according to the Internet standard RFC-822. The USENET
News standard is more restrictive than the Internet standard,
placing additional requirements on each message and forbidding use
of certain Internet features. However, it should always be possible
to use a tool expecting an Internet message to process a news
message. In any situation where this standard conflicts with the
Internet standard, RFC-822 should be considered correct and this
standard in error.
C'était déjà là dans la RFC 850 datée de 1983.
Et c'est bien marqué "basé sur la RFC822" qui n'authorise que l'ASCII.
Et elle n'est pas indiqué obsolete.
D'un autre coté, je prends les "Usenet best practice" (mai 2004).
Ca commence fort:
" Here it shold be noted that what is acceptable in Email (which is a
one-to-few communication where the author can be expected to be aware
of the capabilities and preferences of his correspondents) may not be
acceptable in Netnews (which is a one-to-many communication directed
at an unseen and unknown audience). Much grief has arisen in the
past from poorly designed agents which tried to imppose onto Usenet
defaults and practices which were perfectly appropriate for Email.
"
Ce qui veut bien dire que les news n'acceptent pas tout ce que le mail
accepte mais sont par contre lisibles en tant que mail.
" Subject-headers are for humans to read, and the most that user agents
should do is to filter them as directed by their human readers. If
some enhancement to Netnews requires support within the headers, then
the proper procedure is to invent a new header for the purpose, or to
adapt an existing header (supposing it had the capability to support
such adaptations).
"
Ce qui veut dire que si on veut faire des extensions au header "Subject"
il faut employer un autre header non standard.
Le seul endroit ou on parle de charset, de MIME dans ce document est pour
la construction et l'interprétation du body, jamais pour les headers.
Le dernier draft disponible sur les news (qui date de septembre 2004 mais
n'est pas publié en tant que RFC et encore moins approuvé)
parle lui, effectivement de type MIME dans les headers de news:
" The character set for headers is US-ASCII. Where the use of
non-ASCII characters is required, they MUST be encoded using the MIME
mechanisms defined in [RFC2045] and [RFC2231].
"
Le problème, c'est qu'il n'est pas approuvé:
"Usenet Format Working Group C. Lindsey
Internet-Draft University of Manchester
Obsoletes: 1036 (if approved) K. Murchison
Expires: March 15, 2005 Oceana Matrix Ltd.
D. Kohn
Skymoon Ventures
September 14, 2004
"
Donc, dans l'intervalle, ça reste interdit puisque la référence est
encore la RFC 1036 qui se base sur la 822 qui n'authorise que l'ASCII
dans les headers.
Cf: <http://www.karlsruhe.org/rfc/draft-ietf-usefor-usefor-01.txt>
j'ai profité de cette lecture pour corriger mon profil en rajoutant
.invalid à la fin de mon addresse, comme spécifié (comme quoi, c'est
utile de lire les RFC et drafts...).
On Mon, 06 Dec 2004 14:34:48 +0000, Laurent Wacrenier wrote:
Grrrr écrit:
Non voir le RFC 2047.
Usenet, c'est du mail ? C'est nouveau ?
Non, voir RFC 1036 (Standard for Interchange of USENET Messages) :
(...) Therefore, the rule is adopted that all USENET news messages must be formatted as valid Internet mail messages, according to the Internet standard RFC-822. The USENET News standard is more restrictive than the Internet standard, placing additional requirements on each message and forbidding use of certain Internet features. However, it should always be possible to use a tool expecting an Internet message to process a news message. In any situation where this standard conflicts with the Internet standard, RFC-822 should be considered correct and this standard in error.
C'était déjà là dans la RFC 850 datée de 1983.
Et c'est bien marqué "basé sur la RFC822" qui n'authorise que l'ASCII. Et elle n'est pas indiqué obsolete. D'un autre coté, je prends les "Usenet best practice" (mai 2004). Ca commence fort: " Here it shold be noted that what is acceptable in Email (which is a one-to-few communication where the author can be expected to be aware of the capabilities and preferences of his correspondents) may not be acceptable in Netnews (which is a one-to-many communication directed at an unseen and unknown audience). Much grief has arisen in the past from poorly designed agents which tried to imppose onto Usenet defaults and practices which were perfectly appropriate for Email. " Ce qui veut bien dire que les news n'acceptent pas tout ce que le mail accepte mais sont par contre lisibles en tant que mail.
" Subject-headers are for humans to read, and the most that user agents should do is to filter them as directed by their human readers. If some enhancement to Netnews requires support within the headers, then the proper procedure is to invent a new header for the purpose, or to adapt an existing header (supposing it had the capability to support such adaptations). " Ce qui veut dire que si on veut faire des extensions au header "Subject" il faut employer un autre header non standard. Le seul endroit ou on parle de charset, de MIME dans ce document est pour la construction et l'interprétation du body, jamais pour les headers.
Le dernier draft disponible sur les news (qui date de septembre 2004 mais n'est pas publié en tant que RFC et encore moins approuvé) parle lui, effectivement de type MIME dans les headers de news: " The character set for headers is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2045] and [RFC2231]. " Le problème, c'est qu'il n'est pas approuvé:
"Usenet Format Working Group C. Lindsey Internet-Draft University of Manchester Obsoletes: 1036 (if approved) K. Murchison Expires: March 15, 2005 Oceana Matrix Ltd. D. Kohn Skymoon Ventures September 14, 2004 "
Donc, dans l'intervalle, ça reste interdit puisque la référence est encore la RFC 1036 qui se base sur la 822 qui n'authorise que l'ASCII dans les headers. Cf: <http://www.karlsruhe.org/rfc/draft-ietf-usefor-usefor-01.txt>
j'ai profité de cette lecture pour corriger mon profil en rajoutant .invalid à la fin de mon addresse, comme spécifié (comme quoi, c'est utile de lire les RFC et drafts...).
