Newsgroup: it.comp.software.newsreader
Titolo: [Pimmy] e la decodifica dei subject

Visualizzando con pimmy un recente thread su questo gruppo, compare uno
spazio nel bel mezzo di una parola [finalment e] che visualizzata con
Dialog, invece appare normalmente
"Re: Agent 2.0 finalment e è uscito: prime i mpressioni"
Problema di decodifica degli header contenenti accentate?
Subject: Re: =?ISO-8859-1?Q?Agent_2.0_finalment?=
 =?ISO-8859-1?Q?e_=E8_uscito:_prime_i?=
 =?ISO-8859-1?Q?mpressioni?=
N.B. alcuni (pochi) messaggi di quel thread si vedono bene, forse i più
vecchi, o forse dipende da chi aveva scritto subito prima, cmq dovrebbere
esserci un qualche problema di qualcheduno da qualche parte 
Subject: Re: Agent 2.0 finalmente
=?iso-8859-15?q?=E8_uscito=3A_prime_impressioni?=

 =?ISO-8859-1?Q?mpressioni?=
Il problema consiste nel fatto che la parola "finalmente" è troncata per
andare a capo e nell'unione delle righe compare quello spazio.
Sto cercando di capire se il messaggio è corretto e sbaglia Pimmy. Le RFC
mi sembra che dicano che lo spazio resta quando si uniscono le righe.
-- 
-antonio-
www.geminisoft.com
(do not use this email address)

Dialog, invece appare normalmente
Sai che "dietro" a Mime-proxy non me ne ero accorto?
(la fa vedere giusta).
Ciao.
-- 
 /   _ _ | Xnews e la documentazione in italiano
( (/( (/ | 
http://web.lacasadialice.it/alanford/

 "dietro" a Mime-proxy non me ne ero accorto?
Ed anche su gugle si vede male cioč con lo spazio in mezzo alla parola,
non che gugle sia da prendere come riferimento assoluto, a volte
sbagliano anche loro. Ho posto la stessa domanda anche nel 3d dove lo ho
notato, ma lě sono in tutte altre faccende affaccendati.. (hanno le vene
del collo che a momenti scoppiano.. mha..  :-(

 Ed anche su gugle si vede male cioè con lo spazio in mezzo alla parola,
Ho controllato, ed anche Xnews *senza* Mime-proxy ha gli stessi problemi
di Pimmy (forse in misura maggiore):
 
http://web.lacasadialice.it/alanford/shot/agent2.png
Dal poco che comprendo (per miei limiti) mi sembra che il colpevole sia
proprio *Fr3ddie*


 parola, 
Ho controllato, ed anche Xnews *senza* Mime-proxy ha gli stessi
problemi di Pimmy (forse in misura maggiore):
 
http://web.lacasadialice.it/alanford/shot/agent2.png
Dal poco che comprendo (per miei limiti) mi sembra che il colpevole 
(per modo di dire) sia proprio *Fr3ddie*, seguito da *Sleepers* e 
*Luca*...



Potete dirmi se uno dei due subject č scorretto e perché?
-- 
Luca - e-mail: p.stevens at 
libero.it

 Potete dirmi se uno dei due subject è scorretto e perché?
Passo :)


 Passo :)
Intanto leggi qui, che domani ti faccio leggere quello del Mime, e poi ci
fai il riassuntino serale..
[RFC2822] 2.2.3. Long Header Fields
   Each header field is logically a single line of characters comprising
   the field name, the colon, and the field body.  For convenience
   however, and to deal with the 998/78 character limitations per line,
   the field body portion of a header field can be split into a multiple
   line representation; this is called "folding".  The general rule is
   that wherever this standard allows for folding white space (not
   simply WSP characters), a CRLF may be inserted before any WSP.  For
   example, the header field:
           Subject: This is a test
   can be represented as:
           Subject: This
            is a test
   Note: Though structured field bodies are defined in such a way that
   folding can take place between many of the lexical tokens (and even
   within some of the lexical tokens), folding SHOULD be limited to
   placing the CRLF at higher-level syntactic breaks.  For instance, if
   a field body is defined as comma-separated values, it is recommended
   that folding occur after the comma separating the structured items in
   preference to other places where the field could be folded, even if
   it is allowed elsewhere.
   The process of moving from this folded multiple-line representation
   of a header field to its single line representation is called
   "unfolding". Unfolding is accomplished by simply removing any CRLF
   that is immediately followed by WSP.  Each header field should be
   treated in its unfolded form for further syntactic and semantic
   evaluation.

 fai il riassuntino serale..
                          News Article Format
                   <draft-ietf-usefor-article-11.txt>
4.4.1.  Character Sets within Article Headers
   Where the use of non-ASCII characters is required, they MUST be
   encoded using the MIME mechanisms defined in [RFC 2047] and [RFC
   2231].
   Examples:
      Organization: Technische =?iso-8859-1?Q?Universit=E4t_M=FCnchen?=
      Approved: =?iso-8859-1?Q?Fran=E7ois_Faur=E9?= <f...@modsite.example>
         (=?iso-8859-1?Q*fr?Mod=E9rateur_autoris=E9?=)
      Archive: yes; filename*=iso-8859-1'es'ma=F1ana.txt
        NOTE: The raw use of non-ASCII character sets or of encodings
        other than those described above is not compliant with this
        standard, even though such usage has been seen in some
        hierarchies (with no indication of which character set has been
        used beyond the user's ability to guess based upon other clues
        in the article, or custom within the newsgroup). Future
        extensions to this standard may make provision for other
        character sets, hence the requirement that octets beyond the
        US-ASCII range be transported without error.

   evaluation.
E' questo il punto, credo. Rimuovendo il CRLF (carriage return line feed,
ovvero i due caratteri dell'accapo - lo dico solo per chi non ha
dimestichezza [non mi picchiate]) resta lo spazio.


            is a test
La regola qui riportata (folding) dice che si può inserire un CRLF *prima*
di uno spazio (o un tab) quindi nel subject
Subject: Re: =?ISO-8859-1?Q?Agent_2.0_finalment?=
 =?ISO-8859-1?Q?e_=E8_uscito:_prime_i?=
 =?ISO-8859-1?Q?mpressioni?=
l'errore credo sia stato nell'andare a capo troncando la parola. Il CRLF
andrebbe messo dove già è presente uno spazio.
La procedura inversa (unfolding) difatti rimuove il CRLF ma lascia lo
spazio.
Ciao
-- 
-angelo-
www.geminisoft.com

 spazio.
Io, gnurantissimo, ho problemi a capire la regola così come l'hanno
scritta. In particolare non capisco la differenza tra "white space" e
"simply WSP charachter", e quindi ho dubbi sul significato dell'intera
frase "wherever this standard allows for folding white space". 
Mi chiedo, lo spazio da mantenere quando si fa l'unfolding, non è forse
solo l'underscore nella codifica?
Subject: =?ISO-8859-1?Q?Agent_2.0_finalment?=
 =?ISO-8859-1?Q?e_=E8_uscito:_prime_i?=
^                ^
eliminare        mantenere
Perché se fosse come dite, si dovrebbe finire per avere un doppio spazio
nel caso che il folding fosse stato fatto prima dello spazio, cioè così:
Subject: =?ISO-8859-1?Q?Agent_2.0_finalmente?=
 =?ISO-8859-1?Q?_=E8_uscito:_prime_i?=
^               ^
1               2
Sbaglio?


 Io, gnurantissimo, ho problemi a capire la regola cosě come l'hanno
Scrivono in burocratichese stretto..
piuttosto una domanda, hai provato con la vecchia versione se si comporta
nello stesso modo? Non capisco come mai abbia spezzato su tre righe un
header che non era affatto troppo lungo..

1               2
Io credo che lo spazio non andasse codificato ovvero il subject doveva
essere spezzato così:
Subject: =?ISO-8859-1?Q?Agent_2.0_finalmente?=
 =?ISO-8859-1?Q?=E8_uscito:_prime_i?=
senza l'underscore prima della "e" accentata.
Almeno credo...
Ciao
-- 
-angelo-
www.geminisoft.com





Ho inserito uno spazio in "finalmente":
Subject: Agent 2.0 finalment e č uscito: prime impressioni
                            ^
Agent ha fatto il folding nello stesso punto, e ha inserito l'underscore
per riportare lo spazio nella nuova riga:
Subject: =?ISO-8859-1?Q?Agent_2.0_finalment?=
 =?ISO-8859-1?Q?_e_=E8_uscito:_prime_?=
                ^
 =?ISO-8859-1?Q?impressioni?=
A me questo sembra un comportamento molto sensato, cosě a lume di naso.
Come lo visualizza pimmy? A rigor di logica dovrebbe riattaccare la "e"
a "finalment", mentre in una analoga operazione all'inverso (ossia
facendo il folding quando spedisce un post) dovrebbe non mettere
l'underscore all'inizio della nuova riga, aspettandosi che i client in
lettura reinseriscano lo spazio. Sempre solo a lume di naso, mi
sembrerebbe bizzarro se si dovesse davvero far cosě.



Ho inserito uno spazio in "finalmente":
Subject: Agent 2.0 finalment e č uscito: prime impressioni
                            ^
Agent ha fatto il folding nello stesso punto, e ha inserito l'underscore
per riportare lo spazio nella nuova riga:
Subject: =?ISO-8859-1?Q?Agent_2.0_finalment?=
 =?ISO-8859-1?Q?_e_=E8_uscito:_prime_?=
                ^
 =?ISO-8859-1?Q?impressioni?=
A me questo sembra un comportamento molto sensato, cosě a lume di naso.
Come lo visualizza Pimmy? 
A rigor di logica dovrebbe visualizzare il subject con due spazi in
"finalment  e". In una analoga operazione all'inverso (ossia facendo il
folding quando spedisce un post) dovrebbe non mettere l'underscore
all'inizio della nuova riga, aspettandosi che i client in lettura
reinseriscano lo spazio, altrimenti le due parole finiscono riattaccate.
Sempre solo a lume di naso, mi sembrerebbe bizzarro se si dovesse
davvero far cosě.
-- 


 l'underscore all'inizio della nuova riga, 
Sempre a rigor di logica (?), spedendo un post come quello, non avrebbe
nessun motivo di stare a perder tempo a crearsi una nuova riga, si
rimarrebbe sempre entro le 78 colonne anche mettendoci i caratteri che
servono per la codifica. 
Questo mi fa pensare che qualcosa stia lavorando male. 

Come lo visualizza Pimmy? 
Lo visualizza solo con uno spazio:
Subject: Agent 2.0 finalment e è uscito: prime impressioni
ma in realtà sbaglia perchè avrebbe dovuto mettere due spazi "finalment 
e". Per me questo è un bug di Pimmy.
Ciao
-- 
-angelo-
www.geminisoft.com

 l'underscore non c'è,
spazio non c'è, però ci sono tre spazi all'inizio della seconda riga,
quindi lo stesso non capisco. 
Però c'è una cosa che mi sembra decisiva: se la regola fosse quella che
dici tu, allora inserire un campo più lungo del massimo consentito (78?)
e senza spazi dovrebbe essere esplicitamente proibito, perché sarebbe
impossibile fare l'unfolding correttamente.


Questo mi fa pensare che qualcosa stia lavorando male. 
Ti riferisci ad Agent? :-)
-- 
Antonio |                         - CERCO LAVORO -                       
Paolini | Sono laureato in "Ingegneria Elettronica" (vecchio ordinamento). 
        | Se sei interessato puoi trovare il mio Curriculum Vitae e i dati
	| personali per contattarmi qui: 
http://www.geminisoft.com/paolini

 Questo mi fa pensare che qualcosa stia lavorando male. 
Beh dipende dalla strategia adottata, e a leggere lo standard non ce ne
è _una_ precisa da seguire. Mi pare che anche Agent vada accapo non
appena cìè una parola encodata.
-- 
I just want revenge. Is that so wrong? 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 Mi pare che anche Agent vada accapo
In effetti, forse mi ero espresso non molto chiaramente (rispondo anche a
Lo smilzo), mi riferivo proprio al fatto che era Agent (e del resto pimmy
lo ha scritto su una sola riga) ad andare a capo un po' troppo spesso con
l'effetto come abbiamo potuto notare, che le cose si complicano ancora di
più di quanto già siano complicate e difficili

 più di quanto già siano complicate e difficili
Si OK, anche io avevo seguito distrattamente il thread ...
cmq per quanto discutibile (non piace nemmeno a me) il comportamente di
Agent mi sembra aderente allo standard.
-- 
It's morally wrong to allow suckers to keep their money. 


dici tu, allora inserire un campo più lungo del massimo consentito (78?)
Il massimo dovrebbe essere 998.
Non dovrebbe essere difficile gestire il troncamento tra parole invece che
"a caso". Quindi immagino che siano state fatte delle scelte per precisi
motivi. La curiosità ora è conocere questi motivi.
BTW anche Mozilla mail tronca un po' come gli pare.
Ciao.

 su it.test) ma neanche
abbiano modo di spedire correttamente un messaggio con lo stesso
subject, perché se lo codificano spezzato non lo visualizzano, ma se non
lo spezzano sforano in lunghezza.


|   in the unencoded text.)
Pimmy non si comporta cosě, come abbiamo visto. Personalmente non condivido
la scelta di inserire una modifica di questo tipo solo per permettere di
andare a capo dove si vuole, cosě come quella di avere righe di 76
caratteri quando altrove si dice diversamente. Comunque... se l'rfc dice
questo...


                                                ^
| If it is desirable to encode more text than will fit in an
| 'encoded-word' of 75 characters, multiple 'encoded-word's (separated
| by CRLF SPACE) may be used.
dato che eventuali spazi anche multipli non contano, ammesso che siano
tra due adiacenti "encodedword"

 (80 caratteri)
Caspita, in pratica tutti sbagliati tranne Thunderbird ...
-- 
I may have my faults, but being wrong isn't one of them.


 /parolacodificata/ non la lunghezza dell'header
Si però al paragrafo successivo dice:
|   While there is no limit to the length of a multiple-line header
|   field, each line of a header field that contains one or more
|   'encoded-word's is limited to 76 characters.
-- 
Cute and interesting are two different things.


 | by CRLF SPACE) may be used.
Si, ma in ogni caso bisogna andare a capo, per via della massima
lunghezza riga superata. 


 codifica un nuovo messaggio con lo stesso famigerato subject)
Eccoti accontentato:
|| Subject: Agent 2.0 finalmente =?iso-8859-1?Q?=E8?= uscito: prime impressioni
|| Newsgroups: it-alt.test
|| User-Agent: 40tude_Dialog/2.0.10.60it (cc56bcc2.433.21)
|| Date: Mon, 23 Feb 2004 05:32:24 +0100
|| Message-ID: <9udnzbvn...@shadowfax.ithn.invalid>
Fa esattamente come MT-Newswatcher, Gnus e tin :)
-- 
Fare Well! | it-alt.* CMS (CGFI) ~ 
http://www.x-privat.org/it-alt
G          | 40tude Dialog 2.0.10.1 ß33 ~ 
http://snurl.com/dialog
Now Playing: Anggun - Still reminds me

 Fa esattamente come MT-Newswatcher, Gnus e tin :)
Però manca il "Re: ". Con quattro caratteri in meno sei esattamente a
76, quindi entro i limiti della RFC. Bisognerebbe provare aggiungendo il
Re, per vedere se va a capo. 


 
|Subject: Re: Agent 2.0 finalmente =?iso-8859-1?Q?=E8?= uscito: prime impressioni
|User-Agent: 40tude_Dialog/2.0.10.1it
Anche Dialog, quindi, 80 caratteri senza andare a capo. Sembra proprio
che quella RFC non l'abbiano letta in molti :-)
Scusatemi per il followup sbagliato nell'altro messaggio. 
-- 
Sono in corso le votazioni per questi gruppi, ultima chiamata:
  it.comp.software.editor:
 
news:MK.it.comp.soft...@id.news.nic.it
  it.comp.os.freebsd:
 
news:MK.it.comp.o...@id.news.nic.it


 che quella RFC non l'abbiano letta in molti :-)
A parte che non ho capito quando il nome del campo entra a far parte
della lunghezza della linea oppure no, anche il discorso di limitarsi a
76 non mi è chiaro. Cosa vuol dire "While there is no limit to the
length" ? ci sono header che si comportano diversamente riguardo la
lunghezza, o no? perché per alcuni potrebbe valere una cosa mentre per
altri una altra. (ci sono quelli strurati e quelli non strutturati)
Perché mettere un limite nuovo a 76 quando ce ne sarebbe già uno più
generico su 78/998? E comunque anche volendo applicare il limite più
rigoroso (76 compreso Subject:) sarebbero bastate pur sempre due righe,
come mai tre spezzando impressioni? quale automatismo strano sarà
intervenuto??

 intervenuto??
Dici in Agent? L'algoritmo che regola la faccenda tiene evidentemente
conto di un limite più ristretto. Non so perché ma non credo che ci sia
una ragione particolare.
-- 
