Buenos Laborables Dias.
He decidido retomar este hilo o bump the thread como se dice en los foros
web (al alguien responder algo en un hilo viejo el hilo viejo olvidado de
pronto salta o bump al inicio arrastrando el resto de las respuestas de ese
hilo como mismo sucede por ej en los emails de alguien que Cómo yo los
organiza por conversacion no sólo por orden de llegada) pata resumir las
ideas vertidas en el mismo. Partiré de 2 escenarios posibles; Usando
Aquamail y Usando cual quier otro interfaz o gestor de email.
Como bien dice ATS inicialmente email usaba 7bit pues era suficiente para
representar todo el alfabeto ASCII que al ser diseñado por los americanos
para el idioma inglés entonces solo soporta el alfabeto inglés y el resto
de símbolos del teclado QWERTY para idioma inglés. Eso imponía una
limitación para los usuarios de email de lis inicios que se comunicaban en
Español por ejemplo.
Además otra limitación que se continua arrastrando es que cada línea de
texto es de solo 76 caracteres, por ende aunque usted escriba 100
caracteres en una misma linea los sistemas de email rompen la linea o break
cuando llegan al carácter 76 y ponen el resto debajo en otra línea para sus
transmisión. Es por ello por ejemplo que cuando se usan tipos de Encoding
Binarios como BASE64 si un humano viera el email mientras viaja de un
servidor a otro en realidad lo que ve son bloques de líneas de jeroglíficos
de solo 76 caracteres de largo.
Nada de esto en el mundo moderno los usuarios finales y promedios lo ven,
de hecho el usuario promedio o muchos usuarios de email cuando redactan o
componen o crean sus email ni siquiera se molestan en romper o break la
linea y todo lo escriben como si fuera un solo párrafo o en una línea
inmensa que nunca parece terminar. Por ej yo ahora estoy escribiendo esto
desde el Note 3 y realmente no esto rompiendo la linea o break pues como la
pantalla es tan pequeña el celular tal parece que lo hace pero en realidad
no y por eso en este caso solo hago Hard break o rompo la linea de forma
permanente para dividir lo que escribo en párrafos. Pero si por el
contrario yo hubiera es todo sentado frente a la PC cuyo monitor es de 23
pulgadas entonces si redactará este mismo email yo mismo cada unos 80
caracteres diera CR o Carriage Return o si prefiere apretaria la tecla
Return también llamada Enter en muchos teclados con el objetivo de comenzar
una nueva línea como mismo se hacía 20 o 30 años atrás en las máquinas de
escribir. De hecho esa tecla se llama CR o Return precisamente por que
antes todo se escribía en máquinas de escribir o en teletipos y en esos
sistemas los caracteres se imprimían o escribían en la misma posición pero
había un mecanismo que movía horizontalmente el Carriage o cartucho o
rodillo que contenía en si el papel y cuando uno llegaba al final tenía que
regresar el rodillo o sea Carriage Return con una palanca a tal efecto.
Pues buen, por que esta trova histórica y mañanera entonces?. Pues
precisamente porque para los que usamos el viejisimo ECARTIS como servidor
de Listas de Discusión estos conceptos originales sobre los que evolucionó
el sistema de email moderno son importantisimos pues ECARTIS al quedarse en
la versión 1 de décadas atrás arrastra todas estas limitaciones consigo y
debemos tenerlas en cuenta.
En otras palabras a diferencia de los gestores de email modernos que si
pueden procesar todo esto para ECARTIS un Asunto o un campo To: o incluso
el campo Fecha: en fin cualquier Header o Encabezado, solo puede tener 76
caracteres como máximo, en realidad creo sólo 72 aunque no se porque esa
cifra y no 76 como especificaba inicialmente el estándar de email en sus
inicios. Eso implica que nosotros , al menos para los emails que enviemos a
listas soportadas en el dominio Freelists.org, no debemos escribir Asuntos
muy largos ni nombres de email muy largos pues sino a la hora de crear el
compendio o Digest que es forzosamente un solo texto simple e
intencionalmente compatible con esos primeros sistemas de email , entonces
ECARTIS cortaría el Asunto o nombre de email y descartaría el texto más
allá de 72 caracteres. Por eso yo llamaba la atención sobre evitar las
cadenetas de secuencias de cubacel y RE en lis Asuntos pues sino los más de
50 miembros qye sólo leen los Digest llega el momento que en el Asunto sólo
dice cubacel y RE repetido 5 o 6 veces. Esa limitación de 72 caracteres
también explica pir ejemplo porque en los Digest para los usuarios Yahoo y
ProtonMail sus nombres de email que el sistema DMARC les redacta o cambia
aparecen cortados sl final si se les compara con el mismo email recibido en
tiempo real por la lista.
Ya les digo, el usuario promedio de email ni se percata ni se entera de
esto pues no conoce su existencia, especialmente los jóvenes que nunca
siquiera escribieron nada en una hoja de papel en una máquina de escribir
precisamente porque internamente esa es la función de los gestores de email
, acomodar o modificar esos emails que viajan de esa forma y visualizarlos
o mostrarlos adecuadamente en nuestros terminales.
Así que ya saben , se les agradecería si al redactar Aduntos, no los hacen
muy extensos y que no pasen de 72 caracteres. En realidad ECARTIS adiciona
primero la palabra cubacel pero para crear el Digest la quita y ademas
reacomoda la ubicacion de RE: en los Reply y quizás por eso es que es 72
caracteres.
La otra limitación importante mencionada por ATS es precisamente que la red
ARPANET que es la madre o el origen del Internet moderno y donde se creó y
se empezó a usar el email por primera vez al ser un invento americano
obviamente uso desde sus inicios el formato o mapa de caracteres ASCII
basado en el idioma Inglés que a diferencia del idioma Español no posee
caracteres "especiales" como los acentos de las vocales hispanas o la ñ de
niño por ende oara el viejo ECARTIS como mismo sucedió con los primeros
gestores de emails o gestores más viejos estos tipos de caracteres
generaban problemas y no podían ser visualizados o representados
correctamente y esto implica que nostros, miembros de esra lusra, al
redactar o componer nuestros emails a la lista debemos tener lo en cuenta y
por ende no debemos usar esos acentos o la ñ en ningún Header o encabezado.
En conclusión , por favor , se le agradecerá si en el futuro usted no
escribe Asuntos con acentos y si ademas, muy importante, no usa el acento
en su propio nombre. Eso explica porque en todos mis gestores de email yo
perdí el acento latino en mi nombre o sea lo escribo como Juan J. Fernandez
en vez de usar José y Fernández . OJO: Esto sólo favorece y enormemente a
los más de 50 miembros que leen el Digest cada día pues el resto que lis
recibimos en tiempo real nuestros sistemas de email modernos son capaces de
mostrar esos acentos sin problema alguno pero como dije antes , en la bida,
que usted no perciba o vea problema alguno no quiere decir que realmente no
exista problema para otros. Concepto super importante por cierto ,
especialmente a tener en cuenta por aquellos que ejercen funciones de líder
en grupos a cualquier nivel o magnitud.
Nosotros los que vivimos en este hermoso continente mayormente usamos 2
idiomas, Español e Inglés para los cuales los sistemas de Encoding del
alfabeto latino son suficientes. Por eso yo ayer recomendaba configurar
AquaMail para usar solamente o Windows-1252 o ISO-8859-1 de las 9 opciones
posibles que nos brinda Aquamail en las versiones de esa App en ambos
idiomas y resaltó esto pues si un ruso uso ese mismo aquamail pero en la
versión en ruso (eso es incluso cambiables en el menu) verán que entonces
muestra otros sistemas de charset o Encoding distintos más apropiados a esa
área geográfica o más similares al sistema cirilico que creo es como se
llama. No recomiendo el extendido por el mundo UTF-8 pues sino el viejisimo
ECARTIS se pone farruco con los headers o encabezados a la hora de crear el
Digest. Aquamail no permite configurar el tipo de
Content-Transfer-Encoding pues el ruso Vasilyev que lo invento prefiere
tener control sobre ello y lo cambia de 8bit a Quoted Printable en función
de si es cojimos usar Format Flowed y del tipo de charset escogido y ahí si
no se puede hacer nada.
Los que usen otros gestores de email y que los mismos les permitan
configurarlos les sugiero incluso oara sus propios emails personales que
usen también estos charset o mapas de caracteres mencionados a no ser se
comuniquen además en otros idiomas y en ese caso el universal UTF-8 es mas
apropiado. En cuanto al Content-Transfer-Encoding les sugiero u 8bit o el
propio Quoted Printable pues como bien dijo ATS BASE64 aumenta el tamaño de
los email en un 13%.
Uff!!!, y ahora A Trabajar !, Al Fin !!!, jejeje
