Newsgroup: it.comp.software.newsreader
Titolo: header references ed RFC

Secondo son-of-rfc1036 la formattazione del header references viene
cosi` definita:
References-content = message-id *( space message-id )
Nella grandson-of-rfc1036 viene invece definita:
References-content  = msg-id *( CFWS msg-id )
Sono riuscito a capire che CFWS sta per Commented Folding White Space,
ma non mi e` chiaro cosa voglia dire, e che differenza c'e` dal piu`
semplice White Space.
Il perche` di questa mia domanda nasce da come Sylpheed formatta
l'header in questione, e prima di segnalare la cosa volevo essere sicuro
del significato di CFWS.
TIA
-- 
Bye,
Alfredo Amontagna

semplice White Space.
Ho un po' fretta, ora... ;)
http://www.faqs.org/rfcs/rfc2822.html
-- 
Bye.
       Lem
'CLOCK is what you make of it: partecipa ad un progetto diffuso'
  Distributed computing: 
http://www.aspenleaf.com/distributed/


http://www.faqs.org/rfcs/rfc2822.html
E` qui che avevo capito cosa volesse dire la sigla CFWS, ma quel
Commented ed il relativo costrutto continuano ad essere troppo criptici.
E neanche il token FWS mi e` tanto chiaro.
Per esempio la seguente riga
Header1: qualcosa che puo` continuare su piu` righe<LF>
puo` essere riscritta anche cosi`:
Header1: qualcosa<LF>
<WS>che puo` continuare<LF>
<WS>su piu` righe<LF>
con WS che corrisponde indifferentemente a space (ascii 32) o tab
(ascii 9).
Corretto?
Ma se utilizzo tab al posto di space, e faccio unfolding (eliminare <LF>)
non ottengo l'Header1 originale.!?!?


non ottengo l'Header1 originale.!?!?
Appunto.
Tuttavia, ciò non pregiudicherebbe assolutamente nulla, se non 
l'aspetto esteriore, poiché:
   Runs of FWS, comment or CFWS that occur between lexical tokens in a
   structured field header are semantically interpreted as a single
   space character.
Disclaimer: piglia quanto ho scritto con beneficio d'inventario, eh! ;)
Soprattutto nel mio incasinatissimo esempio di CFWS, più sopra, 
potrebbe esserci qualche imprecisione.


   space character.
Ci sono andato vicino o sono ancora in alto mare?
TNX
-- 
Bye,
Alfredo Amontagna

Ci sono andato vicino o sono ancora in alto mare?
Credo tu abbia compreso perfettamente. Anzi, mi pare di voler insegnare
al lupo come si mangiano le pecore. :)
Possiamo dire:
1) Sylpheed, effettivamente, rimaneggia l'header references, perché 
sostituisce dei TAB a degli spazi, se li trova, così da presentare ogni 
msg-id su una sua riga, tutti 'indentati'. Graficamente, mi piace 
parecchio questa soluzione, ma il rimaneggiamento c'è;
2) la struttura sintattica che si richiede all'header references è:
references      =       "References:" 1*msg-id CRLF
msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]
Lasciamo perdere id-left e id-right, che adesso non c'interessano. 
Notiamo, invece, che msg-id ammette esplicitamente la presenza di CFWS, 
quali che siano;
3) visto che il rimaneggiamento è sintatticamente irrilevante, visto 
che parliamo di un header 'tecnico' (serve al NR per ricostruire i 
thread, generalmente non lo si visualizza), visto che la resa grafica è 
IMHO addirittura migliore... per quanto mi riguarda, ben venga.
Insomma, mi pare molto più 'arbitrario' ritoccare la lunghezza delle 
righe quotate di un messaggio cui rispondiamo, se l'autore le aveva 
fatte troppo lunghe (qui l'aspetto estetico è rilevante, perché tutti 
leggiamo il corpo dell'articolo)... eppure mi pare cosa buona e giusta, 
e spesso ritocco, se è necessario;
4) benché sconsigliati, in casi eccezionali sono consentiti 
rimaneggiamenti delle references ben più rilevanti:
Followup agents SHOULD not shorten References  headers.   If
it  is absolutely necessary to shorten the header, as a des-
perate last resort, a followup agent MAY do this by deleting
some  of  the  message IDs.  However, it MUST not delete the
first message ID, the last three message IDs (including that
of  the immediate precursor), or any message ID mentioned in
the body of the followup.  If it is possible  for  the  fol-
lowup agent to determine the Subject content of the articles
identified in the References header, it MUST not delete  the
message  ID of any article where the Subject content changed
(other than by prepending of a back  reference).   The  fol-
lowup  agent MUST not delete any message ID whose local part
ends with "_-_" ... (son of 1036 - sì, so che c'è il grandson,
ma non mi sono ancora aggiornato).
Anche per questo, quindi, non mi preoccuperei.
