2
- Introducción. ¿Qué es un FAQ?
FAQ significa 'Frequently
Asked Questions', es decir, 'Preguntas Hechas
Frecuentemente'.
Internet, en general, y
especialmente Usenet, se han caracterizado desde siempre por su
tendencia a la colaboración y por su pragmatismo.
En los grupos de 'news'
suele suceder que, muy a menudo, se formulan las mismas preguntas.
Para ahorrar a los habituales de los grupos las mismas respuestas
sin dejar de responder a dichas preguntas, se suelen recopilar
ficheros FAQ.
Estos ficheros crecen, mejoran con
el tiempo y las aportaciones de todas las personas interesadas.
Hoy por hoy existen en Usenet miles de FAQs que constituyen una
formidable base de conocimientos y experiencias, patrimonio común
de todos los internautas.
Existe un archivo de los FAQs
"oficiales" de Usenet (los publicados en news.answers)
en: http://www.cis.ohio-state.edu/hypertext/faq/usenet/
Puedes encontrar abundante
información sobre los FAQs en: http://www.ii.com/internet/faqs/
[ Contenido ]
2.1
- Objetivo de este FAQ
Este FAQ tiene por objetivo ayudar
a los nuevos usuarios en su comprensión de Usenet, prestando
atención a los temas que no suelen encontrarse centralizados en
los lugares habituales de información para "novatos";
o, aunque se encuentren, están en inglés.
Y esto, ¿por qué? La razón es
simple y preocupante: el número de usuarios de Usenet crece
vertiginosamente. La relación señal/ruido en los 'newsgroups'
decrece más que linealmente con el número de usuarios. Es
como si sobre una ciudad cualquiera dejaran caer cada noche en paracaídas
cientos, miles de nuevos habitantes completamente
ignorantes de las leyes, usos y costumbres que rigen en esa
ciudad. El efecto es devastador.
[ Contenido ]
2.2
- ¿Dónde puedo encontrar esta FAQ?
Existen
versiones del FAQ traducido al gallego por Ramón
Flores Seijas en:
http://www.simil.com/scg/newsfaq.txt
http://www.simil.com/scg/newsfaq.htm
La versión HTML del FAQ en gallego
ha sido adaptada por Manuel Casal
Lodeiro .
La versión ASCII del FAQ en
gallego se publica a principio de mes en soc.culture.galiza
.
[ Contenido ]
2.3
- Agradecimientos y bienvenida de sugerencias y ayudas.
Quiero agradecer su colaboración
a:
Fran
Bernal Fernández
Alain Deckers
Javier Herrera
Pedro
Macanás Valverde
Francisco Pleguezuelos (html
y actualización a Julio 2001)
Julio
Sánchez
Domènec Sos (html)
Brad
Templeton
También doy, de antemano, las
gracias a todos los que deseen colaborar en el mantenimiento de
este FAQ con sus preguntas, sugerencias y aportaciones.
Para estos temas podéis dirigir un
mail a miguelc@bitmailer.net
y a admin.news@csi.uned.es
[ Contenido ]
2.4
- Advertencia
La información contenida en este
FAQ no se acompaña, ni explícita ni implícitamente, de ningún
tipo de garantía. Se ha hecho todo lo posible para asegurar la
exactitud de dicha información, pero ni el autor ni las personas
que han contribuido asumen responsabilidad alguna por los posibles
errores u omisiones ni por los daños que puedan derivarse de su
uso.
[ Contenido ]
2.5
- 'Copyright'.
El 'Copyright' de este FAQ
pertenece a su autor, Miguel Conde, y a todas las personas que han
contribuido tal como se menciona en el texto del FAQ.
Se autoriza y se anima a
distribuir, traducir y hacer uso de este FAQ siempre que sea sin
animo de lucro y se notifique previamente a su autor. Si se
reutilizan partes o contenidos debe especificarse claramente el
origen (haciendo constar el URL de acceso).
[ Contenido ]
3
- ¿Cómo funcionan las 'news'?
La primera vez que trates de usar
las 'news' tendrás que enfrentar dos problemas: primero
tendrás que aprender a manejar tu programa lector; segundo, y no
sólo para sacarle el máximo partido posible a las 'news',
sino también para que el respeto y la educación guíen tus
relaciones con los demás usuarios, tarde o temprano tendrás que
aprender cómo funcionan "por dentro" las 'news'.
Aunque solo sean sus fundamentos.
Pero aun antes de dominar ambos
problemas conviene que tengas algo muy claro acerca de cómo
funcionan las 'news', no "técnicamente", sino
"filosóficamente": el éxito de las 'news' hasta
ahora es consecuencia de un único principio: 'give as much
as you take' ('Da tanto como cojas'). Esto quiere
decir que la única forma de que tu experiencia en Usenet te
resulte enriquecedora depende de que pongas a disposición de los
demás todo lo que puedas. La puesta en común de la experiencia,
el conocimiento, la buena voluntad, las charlas, las discusiones,
etc, es lo que hace que Usenet sea "más que la simple suma
de sus partes", por decirlo de alguna manera. Esto es lo mas
importante que puedes sacar de este FAQ.
[ Contenido ]
3.1
- ¿Cómo es eso de que mi lector de 'news' es un
'cliente'? ¿Qué es un 'servidor' de 'news' ?
Para leer las news y enviar
artículos se utiliza un lector de 'news' (tin, rn,
los lectores de Netscape o Microsoft, etc...). Este programa
lector es cliente de otro programa, llamado (claro) servidor, que
es el que se encarga de almacenar, enviar, recibir y gestionar
los artículos. Cuando arrancas tu lector de news, éste se
encarga de comunicarse con un servidor de news para
solicitar, de cada grupo al que estés suscrito, el número total
de artículos y los que están sin leer.
Si lees las 'news' desde
casa, el lector (cliente) está en tu PC y el servidor suele estar
en las instalaciones de tu proveedor (en el ordenador que has
indicado como 'NNTP server' al instalar tu lector; si estás
en una organización (Universidad, empresa...), el servidor suele
estar en una máquina de la organización con la que el cliente se
comunica (también normalmente) a través de una Red de Área
Local). Cuando quieres leer los artículos de un grupo, se lo
indicas a tu programa cliente, que se comunica con el programa
servidor para recuperar las cabeceras de los artículos de ese
grupo almacenados en el servidor.
Cuando quieres leer un artículo en
concreto de un grupo, se lo indicas a tu cliente y éste se
encarga de comunicarse con el servidor para recuperar el artículo
en cuestión. Cuando decides responder a un artículo o componer
uno nuevo, tras redactarlo (normalmente con el editor de tu
lector/cliente), el cliente se lo envía al servidor.
Puedes averiguar lo que sucede
después en el punto 3.4 .
[ Contenido ]
3.2
- ¿Qué es un 'followup'?
Cuando quieres responder a un artículo
tienes tres formas de hacerlo. La primera es el 'followup' ('respuesta
a las news'):
-
Si el artículo al que respondes
tiene una línea 'Followup-To:' en su cabecera,
será enviada a los grupos que figuren en dicha línea.
-
Si no la tiene, será enviada a
los grupos donde fue enviado el artículo al que respondes, es
decir, a todos los grupos que figuran en la línea 'Newsgroups:'
de la cabecera.
Responder con 'followups' (a
las 'news') tiene sentido cuando tu respuesta pueda ser
interesante para los lectores del grupo. Sobre esto, es importante
que leas la sección 5 de este FAQ.
[ Contenido ]
3.3
- ¿Qué es un 'thread'?
Los 'followups' originan
"hilos" ("threads") de artículos. De
otra manera: cuando envías tu respuesta a las 'news' ('followup'),
estás siguiendo el hilo de la conversación.
Algunos lectores de 'news' representan gráficamente estos
"hilos" como jerarquías (árboles) de mensajes.
[ Contenido ]
3.4
- ¿De qué otras formas puedo responder un artículo?
Hay otras dos formas de responder a
un artículo:
-
Puedes responder por correo al
autor. Esta opción es la correcta cuando lo que
quieras expresar en tu respuesta seguramente no tenga interés
para los demás lectores del grupo.
-
Por último, también es posible
enviar tu respuesta simultáneamente al autor del artículo
(por e-mail) y a las 'news'. Tiene sentido
cuando quieres cerciorarte de que tu respuesta llega al autor
del articulo respondido. Conviene que, en el cuerpo del artículo,
expliques que has respondido por 'mail' y a las 'news'
(ya que la respuesta por mail le llegará antes al
respondido que la respuesta por 'news').
Como dice Julio
Sánchez:
"Algunos se irritan si les
mandas por mail una copia del mensaje que estás también
enviando al grupo. La llamada 'copia de cortesía' la recibe, no
se da cuenta de que iba también al grupo, contesta en privado,
mientras otras personas han visto la copia del grupo y discuten
acerca de ello. Hay, sin embargo, gente a quien le gusta así.
Dejémoslo en división de opiniones".
[ Contenido ]
3.5
- ¿Cómo se difunden los artículos a lo largo y ancho del mundo?
Tras componer el artículo y enviárselo
al servidor, todas las personas conectadas a nuestro servidor (las
que están en nuestra misma Red de Área Local, en el caso de las
organizaciones, las que tienen el mismo proveedor, en el caso de
que leas las 'news' en casa) podrán leer nuestro artículo
recién terminado, que ya estará almacenado en el servidor común.
Sin embargo, las personas del resto del mundo todavía no podrán
leer nuestro artículo, ya que éste todavía no está almacenado
en sus servidores.
Cuando un servidor de noticias
suministra artículos de 'news' a otro servidor, se dice
que le "alimenta ('feed') noticias"; los artículos
almacenados en nuestro servidor han sido obtenidos de otro nodo de
'news' (o sea, de otro servidor de 'news').
A determinado intervalos de tiempo,
cada servidor de 'news' se conecta con otros para recabar
de ellos los artículos nuevos. Cuando otro servidor (servidor B)
se conecte al nuestro (servidor A) para pedirle los artículos
nuevos, nuestro servidor (A) le enviará cualquier artículo nuevo
que todavía no le haya enviado, entre ellos el que acabamos de
redactar. Desde ese momento, cualquier usuario del servidor B, a
través de su cliente/lector, podrá leer nuestro artículo.
Cuando un servidor C solicite los
artículos nuevos del servidor B, éste le enviará, entre ellos,
nuestro artículo. De esta forma, poco a poco nuestro artículo va
siendo visible en todo el mundo, empezando por nuestro servidor
(inmediato), siguiendo con los servidores directamente conectados
a nuestro servidor (seguramente en el mismo día) y continuando
con otros mas lejanos (2-3 días, 1 semana), hasta aparecer en
todos.
También es posible que un servidor
se conecte con otro para comunicarle que tiene artículos nuevos
que enviarle. Este método se denomina "news push"
("empujar los artículos") en contraste con el otro método
expuesto anteriormente, que se denomina "news pull" ("tirar
de los artículos"). De hecho, el método "news push"
es hoy el más ampliamente utilizado. Hay otras mejoras, también:
Julio
Sánchez explica:
"De hecho, todos los
servidores grandes se configuran para intentar mandar los artículos
a los vecinos cuando todavía están en memoria o en caché de
disco para evitar tener que ir de nuevo al disco para mandarlos
(esto mata el rendimiento de un servidor que recibe muchos artículos
y que tiene muchos vecinos).
Para manejar el push como
digo, los servidores no llaman periódicamente, sino que
mantienen una o más conexiones abiertas todo el rato con sus
vecinos. La propagación es casi instantánea. Muchos artículos
se propagan a siete u ocho saltos del origen en menos de un
cuarto de hora".
El protocolo que se utiliza entre
los servidores y entre los clientes y los servidores se llama NNTP
('Network News Transfer Protocol') y el algoritmo que
utiliza se dice que es de "inundación" ("flooding").
NNTP es un protocolo moderno; antes se utilizaba UUCP (bueno,
todavía se utiliza).
[ Contenido ]
3.6
- ¿Durante cuánto tiempo se guarda un artículo en un servidor?
Para que los artículos nuevos que
se transportan constantemente de servidor a servidor no se
amontonen indefinidamente, lo que se hace es mantener cada artículo
en cada servidor sólo durante un tiempo determinado, transcurrido
el cual el artículo "caduca" ("expire"),
se borra, y deja de ser accesible para los usuarios conectados a
ese servidor. El tiempo de caducidad lo determinan los
administradores de los nodos servidores de artículos. El tiempo
de caducidad puede ser distinto para cada grupo de 'news'.
Suele ser entre 2 días (grupos más frecuentados) y dos semanas
(grupos menos frecuentados).
Alain
Deckers explica:
"Ese tiempo lo controla el
administrador de cada servidor, según los criterios que vea
convenientes. Es decir, en general, el tiempo que un artículo
permanece en determinado grupo varía de un servidor a otro.
Por ejemplo, un centro de I+D que
por los motivos que sea tiene poco espacio de disco disponible
para news, puede guardar los artículos de los grupos
comp.* y sci.* durante dos semanas, los de soc.* y rec.* durante
un día y los de alt.* durante 4 horas. Claro que en realidad,
solo recibiría comp.* y sci.* (salvo que el administrador se
las ingenie para recibir las demás jerarquías
'extra-oficialmente').
Mientras tanto, el servidor de un
proveedor con sobrada capacidad de disco para news puede
quedarse alt.* durante un par de días y todo lo demás durante
una semana.
En la práctica es algo más
complicado de lo puede dar a entender esta explicación,
dependiendo de los detalles de la configuración del servidor.
En cualquier caso, el 'tiempo de caducidad' de los artículos lo
fija cada administrador para su servidor."
[ Contenido ]
3.7
- ¿Qué es y para qué sirve un 'punto neutro'?
Para que todo el sistema funcione más
rápidamente, algunos servidores de 'news' actúan como
'puntos neutros', estaciones de paso que proporcionan artículos
para muchos otros servidores. Una vez que nuestro artículo llega
a uno de estos 'puntos neutros', será enviado a muchos otros
servidores en un corto espacio de tiempo.
[ Contenido
]
3.8
- Resumiendo: las news de un grupo ¿son instantáneas, o
tardan un tiempo desde que se envían hasta que salen publicadas
para su lectura?
Como conclusión de todo lo
anterior: el tiempo que tarda un artículo en estar visible para
un lector depende de desde dónde se envió ese artículo, dónde
está el lector, de la topología física de Usenet y del tiempo
que tardan en comunicarse entre ellos los servidores situados
entre el lector y el escritor del artículo. Si el lector y el
escritor utilizan el mismo servidor, el lector podrá leer
inmediatamente el artículo; si utilizan servidores conectados
directamente, el lector tardará poco en poderlo leer (menos de 1
día); si hay más servidores por el medio, puede tardar hasta
varios días.
Esta es una de las razones por las
que diferentes servidores tienen distintos artículos en los
mismos grupos.
[ Contenido ]
3.9
- ¿Cómo puede ser que a veces lleguen antes los 'followups'
que el artículo que origina el 'thread' ?
La respuesta a esta pregunta se
deja como ejercicio al lector, quien, después de haber leído los
puntos anteriores sobre cómo se distribuyen las 'news', no
debe tener ningún problema para contestarla ;-)
[ Contenido ]
3.10
- '¿Cómo explicar que en estos momentos en mi servidor en el
grupo xx.xx.xx hay YYY mensajes, cuando en otro servidor hay
solamente ZZZ ?'
Alain
Deckers explica:
"No hay ninguna razón que
obligue a todos los servidores a tener el mismo contenido en un
determinado grupo. Esto es algo que a mucha gente le causa sorpresa
cuando lo oyen por primera vez, pero si lo piensas es
bastante lógico.
Primero: cada artículo tarda
cierto tiempo en propagarse de un servidor a otro. En un
determinado momento, en tu servidor habrá artículos que aún
no han llegado a otros servidores y viceversa. Recuerda que la
velocidad de la luz es finita. ;)
Segundo: el administrador de cada
servidor fija los plazos de caducidad de los artículos. Si el
servidor dispone de poco espacio de disco, el ritmo de caducidad
probablemente sea mayor.
Tercero: la mayoría de los
servidores aceptan anulaciones de artículos, pero no todos. Si
tu servidor pertenece al primer grupo, no verás algunos artículos
que si verías si te conectaras a un servidor del segundo grupo.
(Pero no te preocupes que sólo te estás perdiendo artículos
basura del tipo "Pelirroja caliente, llámame" y
"Hazte rico sin trabajar".)
Cuarto: algunos servidores están
configurados para rechazar artículos cruzados a más de X
grupos. [N. del A.: También pueden estar configurados para
cancelar envíos binarios a grupos no específicamente dedicados
a ellos]
Etc, etc, etc.
En tu servidor están los artículos
que tu administrador de news quiere que estén. Para eso
le pagan."
Y Julio
Sánchez completa:
"Alain Deckers ya ha
explicado unas cuantas razones por las que el contenido de los
grupos no es idéntico en diferentes servidores. Yo doy tres más:
- Distribuciones. O sea, lo que
se pone en esa cabecera llamada Distribution que nadie sabe para
qué es ;-) Si un servidor indica que sus vecinos sólo recibirán
artículos con tal y tal distribución (o con todas menos tal y
tal), sólo se propaga un subconjunto de los artículos. También
puede ocurrir que el servidor no acepte todas las
distribuciones, así que los artículos que lleguen a otras
distribuciones se descartan. Por ejemplo, es normal que unos
servidores a otros no se pasen la distribución 'local'. [N. del
A.: ]
- Si un servidor crea un grupo
que no recibe de verdad, sólo aparecerán en el los artículos
que estén enviados a grupos que sí recibe además de a éste.
Es decir, un claro síntoma de que tu proveedor tiene creados más
grupos de los que recibe es que en algunos grupos, todos los artículos
aparecen 'crossposted'.
- Si un servidor tiene
configurados como no moderados algunos grupos que sí son
moderados, los artículos enviados a estos grupos en ese
servidor aparecen, pero son descartados por sus vecinos
correctamente configurados."
[ Contenido ]
3.11
- ¿Es posible que algunos artículos no lleguen nunca a mi
servidor?
Si. Por las razones explicadas en
el punto anterior (plazos de caducidad, artículos cancelados, artículos
rechazados por 'crossposting', distribuciones...) y, además,
porque también se producen errores en el mecanismo de difusión
de artículos (aunque no debería ser muy habitual).
[ Contenido ]
3.12
- ¿Por qué los 'newsgroups' tienen esos nombres tan
raros?
Los grupos de Usenet se organizan
por jerarquías temáticas. Las 8 principales son:
- comp.* (COMPuters,
ordenadores)
- humanities.* (humanidades)
- misc.* (MISCelánea)
- news.* (sobre la misma Usenet)
- rec.* (RECreation, ocio)
- sci.* (SCIence, ciencia)
- soc.* (SOCiety, sociedad)
- talk.* (charla).
Además existe la jerarquía alt.* (ALTernative,
grupos alternativos) y las jerarquías nacionales como es.* (ESpaña)
fr.* (FRance), de.* (DEutchland), etc.
Cada jerarquía se subdivide en
grupos y subjerarquías temáticas: soc.culture.*, soc.history,
sci.phisycs.*, etc.
[ Contenido ]
3.13
- ¿Por qué los diferentes servidores de 'news' no tienen
los mismos 'newsgroups'? ¿Quiere esto decir que igual que
nosotros nos suscribimos a los grupos también los servidores lo
hacen?
Alain
Deckers contesta:
"Si. Hay gente que tiene
servidores de news en un PC en el salón de su casa que sólo
están subscritos a los 4 grupos que leen. Los servidores de
Universidades y empresas (incluyendo los proveedores como Jet,
RedesTB, o el que sea) también pueden elegir no subscribirse a
determinadas jerarquías por las razones que sean. Por ejemplo,
algunos servidores no están subscritos a la subjerarquía
alt.binaries porque ocupa una burrada de espacio de disco (casi
más que todas las demás juntas). Hay muchas otras
razones".
Si, hay que tener en cuenta que
Usenet genera (a "grosso modo") más de 500 Mbytes
diarios de media y crece rápidamente. Almacenar toda esa
información requiere enormes cantidades de disco (bueno, también
se puede optar por hacer que los artículos duren sólo 1 día en
el servidor :-) También hay que considerar los costes (tiempo y
dinero) de la transmisión de esa información. Además, no todos
los sitios con servidores de 'news' están interesados en
todas las jerarquías; por ejemplo, no es corriente que los
servidores españoles tengan la jerarquía finlandesa de 'newsgroups'.
También puede suceder que la política del servidor le impida
tener ciertos grupos: por ejemplo, si el Vaticano tuviera un
servidor de 'news', no creo que tuviera
alt.binary.pictures.sex :-)
[ Contenido ]
3.14
- ¿Cómo se crean los grupos de 'news'?
Los detalles exactos puedes
encontrarlos en:
-
Grupos de las jerarquías "Big8":
ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/creating-newsgroups/part1
-
Grupos de la jerarquía es.*: http://www.rediris.es/netnews/moderacion/docs/como_proponer_grupos_es.txt
http://www.rediris.es/netnews/moderacion/docs/creacion_grupos_es.txt
http://news.rediris.es/~preguntas/news/faqs/es/es-mini-faq
- Grupos de la jerarquía alt.*:
ftp://rtfm.mit.edu/pub/usenet/alt.config/So_You_Want_to_Create_an_Alt_Newsgroup
En pocas palabras, el proceso de
creación de un grupo nuevo en las jerarquías "Big8"
y es.* comprende dos pasos: la discusión previa y la votación.
Primero, la persona que propone el
grupo envía un articulo, llamado RFD ('Request For
Discussion') a los grupos apropiados (según se indica en las
direcciones anteriores) para iniciar en alguno de ellos un periodo
de debate sobre la conveniencia de crear el grupo, si debe ser o
no moderado, cuál debe ser su temática, etc. Transcurrido este
periodo, puede ser necesario recoger las conclusiones de la
discusión en un nuevo RFD (si las modificaciones respecto al
anterior son importantes) y realizar un nuevo proceso de discusión.
Esta primera fase de discusión puede repetirse cuantas veces sea
necesario antes de pasar a la siguiente, la de la votación.
Para la votación se designa una
persona ('votetaker') independiente para que controle y
supervise el proceso. La votación se inicia cuando el 'votetaker'
publica un artículo llamado CFV ('Call For Votes')
recogiendo la fundamentación del grupo (consecuencia del RFD) y
explicando cómo votar por e-mail. Al final del periodo de
votación el 'votetaker' publica los resultados de la
votación y, si se verifican los requisitos de la jerarquía, la
persona responsable de dicha jerarquía crea el grupo. Por
supuesto, la creación del grupo no es inmediata y simultánea en
todos los servidores de Usenet, sino que se va propagando a poco a
poco entre ellos, siendo creado solamente en aquellos servidores
cuyos administradores así lo deseen.
Esta descripción de cómo se crean
los grupos es muy general. Si se desea conocer el proceso en
detalle, se deben leer los documentos citados arriba.
Los CFVs son las auténticas
"cartas fundacionales" de los grupos de Usenet; a ellos
hay que atenerse si se desea saber lo que es o no es correcto y
apropiado en un 'newsgroup'. Existe un archivo de RFDs y
CFVs en: ftp://ftp.uu.net/usenet/news.announce.newgroups/
El estado y el archivo de los RFDs
y CFVs de la jerarquía es.* lo podéis encontrar en: http://news.rediris.es/infonews/news.archive/
[ Contenido ]
3.15
- Servidores públicos de 'news'
La mayoría de los servidores de 'news'
no son de libre acceso. Dan servicio únicamente a los clientes de
su propia red, o sólo a un conjunto determinado de máquinas, o
bien exigen algún tipo de identificación (usuario/contraseña)
para permitir el acceso.
Por el contrario, también es
posible encontrar servidores de 'news' de acceso libre.
Unos tienen más grupos que otros, algunos permiten enviar artículos
y otros solamente leerlos.
El conjunto de servidores públicos
es muy cambiante: algunos de estos servidores no son nada más que
servidores cuyos administradores no pretenden que sean públicos
pero que, al estar mal configurados, permiten el acceso a
cualquiera. Como se puede suponer, en cuanto sus administradores
se dan cuenta dejan de ser públicos. En cualquier caso, siempre
suele tratarse de servidores poco fiables y que dan un servicio de
no muy buena calidad (con las lógicas excepciones).
Cuando sea un proveedor de Internet
el que nos da acceso a un servidor de 'news' tenemos todo
el derecho del mundo, como clientes, a exigirle la calidad de
servicio apropiada, ya que por ella nos cobran. De hecho, deberíamos
acostumbrarnos a hacerlo. Sin embargo, en el caso de los
servidores de libre acceso no nos une con los gestores de dichos
servidores ninguna relación de tipo contractual, así que tampoco
tenemos derecho a exigirles nada.
Es importante dejar muy claras las
condiciones cuando se contrata a un proveedor de Internet. En
cuanto a las 'news', deben aclararnos si nos van a dar
acceso a un servidor propio o público, cuántos grupos tiene,
etc.
[ Contenido ]
3.16
- ¿Por qué veo caracteres "extraños" en algunos
mensajes? ¿Qué es MIME?
La respuesta a esta pregunta exige
una explicación ligeramente técnica. No pretenderé que sea
exhaustiva, y me centraré en los mensajes de texto. Para
profundizar en el tema conviene referirse a los RFCs 1521
y 822.
Traducido del RFC
1521, 'MIME Part One':
"Desde su publicación en
1982, el documento STD
11 , RFC 822, ha definido el formato estándar de los mensajes
textuales de correo en Internet. Su éxito ha sido tal que el RFC
822 ha sido adoptado, total o parcialmente, más allá de los
confines de Internet y del estándar STD
10, RFC 821 de transporte de correo (SMTP). Al incrementarse
su uso, algunas de sus limitaciones se han manifestado
crecientemente restrictivas para la comunidad de usuarios.
El RFC
822 trataba de especificar un formato para mensajes de texto.
Por lo tanto, los mensajes no textuales, como los mensajes
multimedia que pueden incluir audio y vídeo, por ejemplo, ni
siquiera se mencionan. Incluso en el caso de los mensajes
textuales el formato definido en el RFC
822 es inadecuado para las necesidades de los usuarios de
correo cuyos idiomas requieren el uso de conjuntos de caracteres más
ricos que el definido como US-ASCII ..."
[N. del T.: el juego de caracteres
US-ASCII contiene 128 caracteres, codificados con 7 bits, es decir,
del 0 al 127; dichos caracteres son los utilizados en inglés, y,
por tanto, no contiene nuestros caracteres acentuados, nuestra eñe
;-), etc]
La situación todavía se complica
más si consideramos que los estándares de transporte de mensajes
de correo (SMTP, STD
10, RFC 821) y 'news' (NNTP, RFC
1036) especifican que dichos sistemas deben ser capaces de
transportar mensajes compuestos por caracteres codificados en 7
bits. Esto explica que nos encontremos con "zonas" de la
Red que cumplen este estándar y sólo son capaces de transportar
caracteres de 7 bits; otras, sin embargo, también cumplen el estándar
pero son capaces de transportar caracteres de 8 bits (si pueden
transportar caracteres de 8 bits, también son capaces de
transportar caracteres de 7, luego cumplen el estándar).
Pongamos un ejemplo. El carácter 'ó'
corresponde, en el juego de caracteres Latin-1 (iso-8859-1), que
contiene los caracteres específicos de nuestro idioma, al número
243 (F3, en hexadecimal). En binario, este número se escribe 1111
0011. Si enviamos un mensaje que contiene este carácter a través
de una zona de la Red que sólo es capaz de transportar caracteres
de 7 bits, el carácter, al llegar a su destino, se habrá
convertido en 111 0011 (73 hexadecimal). Y el lector de correo en
el destino, ya utilice el juego de caracteres US-ASCII o el Latin-1,
presentará el carácter 's', que es al que corresponde en ambos
juegos (US-ASCII es un subconjunto de Latin-1).
La situación descrita obliga a
"traducir" a 7 bits todos aquellos datos no textuales o
textuales no US-ASCII antes de enviarlos y a deshacer dicha
"traducción" al recibirlos, antes de presentárselos al
usuario.
MIME ('Multipurpose Internet
Mail Extensions', 'Extensiones Multipropósito para Correo en
Internet') proporciona una forma de hacer esto.
Los mensajes con formato MIME se
caracterizan por 3 líneas en su cabecera. Por ejemplo:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=F3
El ejemplo anterior contiene, en el
cuerpo del mensaje, únicamente una 'ó'. Como se ve, el carácter
1111 0011 ha sido traducido (mediante codificación 'quoted-printable'
a 3 caracteres de 7 bits: '=' (011 1101), 'F' (100 0110) y '3'
(011 0011). Cualquier "zona" de la red que cumpla el STD,10
RFC 821, será capaz de transportar estos 3 caracteres, porque
sólo tienen 7 bits. Cuando lleguen a su destino, si el lector de
correo o de 'news' "entiende" MIME, será capaz
de obtener el carácter original. Por una parte, sabe (porque lo
pone en la cabecera del mensaje) que fue codificado como 'quoted-printable',
así que de los caracteres "=F3" obtendrá el carácter
número 243. En la cabecera también dice qué juego de caracteres
debe usar, en este caso el iso-8859-1. Como en ese juego el carácter
243 es la 'ó', eso es lo que presentará al usuario.
Sin embargo, si el lector no
"entiende" MIME, el usuario verá los caracteres
"=F3" tal cual. Y si no dispone en su ordenador del
juego de caracteres iso-8859-1, también verá "cosas extrañas".
La línea 'Content-Type:' se
compone de un par 'tipo/subtipo' (en este caso, 'text/plain')
de datos contenidos en el mensaje más una serie (opcional) de parámetros
(en este caso, 'charset=iso-8859-1'). Otros posibles
'tipos' son 'audio', 'video', 'image', 'application',
etc.
La línea 'Content-Transfer-Encoding:'
puede indicar 5 tipos de codificación: '8bit', '7bit',
'binary', 'quoted-printable' y 'base64'.
- Los valores '8bit', '7bit'
y 'binary' indican que NO hay codificación.
-
Si se emplea '7bit'
es porque el mensaje sólo contiene texto codificable en 7
bits (es decir, contenido en el juego de caracteres US-ASCII).
-
Si se emplea '8bit'
es porque el mensaje contiene texto con algunos caracteres
que necesitan 8 bits para ser codificados (caracteres no
US-ASCII). Si un mensaje de este tipo pasa por una
"zona" de la Red que sólo puede transportar
caracteres de 7 bits, no veremos bien los caracteres que
precisan 8 bits (los que tienen a 1 el bit más alto).
-
Si se emplea 'binary' significa
que no solo hay caracteres no US-ASCII, sino que se
distribuyen en líneas mas largas de lo permitido en el STD
10, RFC 821 (lo que constituye un indicio de que se
trata de datos binarios). Si un mensaje de este tipo pasa
por una "zona" de la Red que sólo puede
transportar caracteres de 7 bits, no llegarán bien los
caracteres que precisan 8 bits (los que tienen a 1 el bit
más alto).
-
Por otro lado, los valores 'quoted-printable'
y 'base64' indican que SI hay codificación
(suele utilizarse 'quoted-printable' para codificar
texto y 'base64' para codificar binarios como audio, vídeo,
aplicaciones, etc). Todos los caracteres (US-ASCII y no US-ASCII)
se codifican como caracteres o grupos de caracteres
codificables con 7 bits, de manera que el mensaje no se
alterará al viajar por la red. Sin embargo, si al llegar al
destino el lector no es capaz de descodificar el mensaje o si,
una vez descodificado, no dispone del juego de caracteres
correspondiente, veremos "caracteres extraños".
Como CONCLUSIÓN:
- Si se desea utilizar caracteres
no US-ASCII (acentos, eñes, etc) podemos:
-
Codificar los mensajes ('quoted-printable'
o 'base64'). Los mensajes llegarán sin
alteración, pero quien no pueda descodificarlos o no
disponga del juego de caracteres adecuado los verá con
"caracteres extraños".
-
No codificarlos ('8bit'
). En tal caso, como el mensaje contiene caracteres que
precisan 8 bits, si pasa por alguna zona que sólo
transporta caracteres de 7 bits o si el ordenador
destino no dispone del mismo juego de caracteres con que
se escribió el mensaje original, el receptor los verá
con "caracteres extraños".
También puede suceder que algún servidor de 'news'
intermedio los codifique por su cuenta (lo indicará con
una línea en la cabecera de este estilo: X-Mime-Autoconverted:
from 8bit to quoted-printable by ...)
-
No utilizar MIME: este caso
es equivalente al de utilizar MIME sin codificación: como
el mensaje contiene caracteres que precisan 8 bits, si
pasa por alguna zona que sólo transporta caracteres de 7
bits o si el ordenador destino no utiliza el mismo juego
de caracteres con que se escribió el mensaje original, el
receptor los verá con "caracteres extraños".
-
La otra opción es utilizar únicamente
caracteres US-ASCII. La ventaja es que todo el mundo verá lo
que escribes sin alteración, utilices MIME o no. La
desventaja es que no podrás utilizar eñes, acentos, etc.
Puedes encontrar algunas
referencias útiles al final de este
documento.
[ Contenido ]
4
- ¿Qué es la netiqueta?
Usenet existe desde hace bastante.
Durante ese tiempo, sus usuarios han ido reuniendo experiencia, de
una manera informal, relativa a los usos más adecuados para una
comunicación efectiva a través de las 'news'. Esta
experiencia, en forma de consejos, se denomina netiqueta;
se trata de la "etiqueta de la red", de sus "reglas
de educación". Son una extrapolación de las normas de
educación que (la mayoría) utilizamos en la vida diaria, aunque
tendemos a olvidar usarlas en la Red, dada la naturaleza virtual
de la interacción social en ella.
No tienen un carácter coercitivo.
Son tan solo consejos, pero de un gran interés práctico. Su
observación condiciona en gran medida el funcionamiento de un
grupo de 'news'. Por ello es sumamente importante
que te familiarices con ella. En la última
sección de este FAQ encontrarás algunas direcciones de
documentos pensados expresamente para ello.
[N. del A.: Javier Herrera propone
una traducción alternativa y más hispanizada del termino 'netiquette';
como este es 'net' + 'etiquette', el equivalente en
español seria 'red' + 'etiqueta', de donde sale el término 'retiqueta'.
Se me ocurre que, como en español no se suele utilizar la palabra
'etiqueta', sino 'educación', el palabro obtenido seria 'red' + 'educación':
'reducación' :-)]
[ Contenido ]
5
- ¿Qué es 'crossposting'?
A poco tiempo que lleves en Usenet
te encontrarás con uno de sus aspectos mas irritantes: el 'crossposting'.
Es posible, incluso, que, sin darte cuenta tú mismo lo estés
cometiendo. Evitar hacerlo tu es fácil. Evitar que lo cometan los
demás ya es más complicado: exige la solidaridad de todos los
usuarios de Usenet.
[ Contenido ]
5.1
- ¿Qué son estos miles de artículos que bombardean mis newsgroups
favoritos y no tienen nada que ver con los temas habituales?
¡¡¡Los encuentro hasta en la sopa!!!
Seguramente se trata de 'crossposting'.
Para estar seguro, comprueba la línea 'Newsgroups:' en la
cabecera de esos artículos. Si aparecen en ella muchos grupos, se
trata de 'crossposting'. Como sufrirás en carne propia, se
trata de uno de los fenómenos más desagradables en Usenet
porque:
-
Nos hace perder tiempo y dinero
a los usuarios. Acaba resultando irritante.
-
Malgasta los recursos (disco,
ancho de banda, etc) que todos compartimos (aunque menos que
el 'spam', ver aptdo. 6).
Añade Alain
Deckers:
"Yo añadiría que el
principal problema asociado al cross-posting es que este
rompe por completo la temática de los grupos, ahuyenta a parte
de la audiencia de las news y en general rompe el sentido
de "comunidad" que solía forjarse antaño en los
grupos con una audiencia fiel."
[ Contenido ]
5.2
- ¿Cómo empieza un 'crossposting'?
Cuando alguien inicia un 'thread'
normalmente envía este primer artículo a un sólo grupo; si lo
dirige a muchos grupos (más de 2 ó 3) y no toma las debidas
precauciones, ver más abajo, inicia un 'crossposting'.
A partir de entonces cualquiera que haga un 'followup' en
ese 'thread', si no cambia la línea 'Newsgroups:'
de la cabecera, estará enviando su artículo a todos esos grupos.
[ Contenido ]
5.3
- ¿Quién inicia los 'crosspostings'?
- Gente inexperta.
- Gente mal intencionada.
[ Contenido ]
5.4
- ¿Puede tener sentido un 'crossposting'?
A veces (raras veces) si. Por
ejemplo, supón que quieres anunciar tu nueva y reluciente pagina 'web'.
Como contiene información sobre los furullos azules ;-)
enseguida piensas en enviar un mensaje a varios grupos de la jerarquía
es.furullos.*. Sin embargo, como has leído
este FAQ, sabes que lo que estás a punto de hacer es un 'crossposting'.
¿Qué hacer ? Para evitar el 'crossposting' puedes
utilizar la línea 'Followup-To:' de la cabecera. Tienes 2
opciones:
-
Si pones 'Followup-To: poster',
los 'followups' a tu artículo no irán a parar a ningún
grupo, sino a ti (por 'e-mail').
-
Si pones 'Followup-To:
es.furullos.azules', los 'followups' a tu artículo
irán a parar sólo al grupo es.furullos.azules. En
este caso es conveniente que, en la cabecera del mensaje,
indiques a tus lectores lo que has hecho, para que sepan que
deben seguir el 'thread' en es.furullos.azules.
[ Contenido ]
5.5
- ¿Cómo puedo evitar el 'crossposting'?
SIEMPRE, SIEMPRE, SIEMPRE comprueba
la línea 'Newsgroups:' antes de enviar cualquier artículo.
Si es imprescindible hacer un 'crossposting',
sigue los consejos del punto anterior.
Envía un 'mail' a los "crossposteadores"
quejándote por su comportamiento. (OJO: he dicho un MAIL; si les
respondes en las 'news', tu mensaje de queja ¡¡¡se sumará
al 'crossposting' !!! ) A veces te encontrarás que tus
mensajes "rebotan" ('user unknown', o similar).
Te remito al 'Net
Abuse FAQ' sobre este tema. Puede que se trate de un
"profesional", pero, aún así, es posible pillarle en
muchos casos.
También puedes quejarte ante el 'postmaster'
del servidor de donde proviene originalmente el 'crossposting'.
Hazte con un lector de 'news' serio
(es decir, con capacidades de 'killfile', un filtro que te
permita eliminar los artículos indeseados, entre ellos los "crossposteados".
¡¡¡Qué paz, que tranquilidad !!!) Esta solución es efectiva
(dejarás de sufrir el problema en gran medida) pero un tanto
"insolidaria" (tú te libras del 'crossposting'
pero,..., ¿qué pasa con la pobre Usenet, eh?)
Como opinión personal, la mejor
solución es convertir los 'newsgroups' en "pseudo-moderados".
La principal (o única) regla de moderación sería el rechazo de
aquellos artículos 'crossposteados', digamos, a más de 4
grupos. Esto se puede hacer automáticamente mediante un programa
"robomoderador" que evite la moderación
humana. Permite también la remisión automática de un 'mail' a
los "crossposteadores" explicando la razón del rechazo
de su artículo.
[ Contenido ]
5.6:
¿Qué es un 'killfile'?
Algunos lectores de 'news' permiten
filtrar los artículos de los grupos. Esto significa que puedes
instruir al lector para que, por ejemplo, no presente los artículos
de determinado autor o de determinado 'thread', o aquellos
que contengan determinadas palabras en el "Subject:"
(por ejemplo, "MAKE MONEY FAST"), o aquellos 'crossposteados'
a más de X grupos. También pueden permitir lo contrario, es
decir, resaltar aquellos artículos que vengan de un autor
determinado, o los de determinado "hilo", o los que
contengan determinadas palabras.
La configuración de estos filtros,
al menos en los primeros lectores de 'news' que
incorporaron esta facilidad (muy ligados al mundo Unix), se guarda
en ficheros ASCII denominados 'killfiles'. así,
"incluir a alguien en mi 'killfile'" equivale a
hacerle desaparecer de Usenet, al menos para mí.
Es indudable la utilidad que pueden
tener los 'killfiles'. La visión que un usuario tiene de
un grupo determinado puede variar drásticamente si usa un 'killfile'.
Sin embargo, no todo son ventajas (al menos, ventajas definitivas:
ver el apartado 'Con los 'killfiles' ¿puede
conseguirse lo mismo que con la moderación automática ?').
[ Contenido ]
6
- ¿Qué es 'spam'?
El 'spam' consiste en
inundar Internet con muchas copias del mismo mensaje (de 'e-mail'
y/o de 'news'), tratando de forzar que lo lea mucha gente,
gente que de otro modo pasaría de leerlo. La mayoría es
publicidad comercial, a menudo de productos cuando menos
"sospechosos" (productos "milagro", por
ejemplo), o del estilo "¡¡¡Hágase rico en hora y media
!!!", o negocios piramidales, etc.
En el caso de las 'news' se
diferencia del 'crossposting' en que, en lugar de tratarse
de1 mensaje dirigido a muchos grupos, consiste en el mismo mensaje
enviado una vez a cada grupo. Por tanto, en la línea 'Newsgroups:'
de la cabecera del mensaje aparecerá sólo un grupo, pero
encontrarás el mismo mensaje en múltiples grupos (Nótese aquí la diferencia con el 'crossposting': un articulo 'spam' dirigido,
digamos, a 20 grupos, se envía 20 veces a cada servidor y se
guarda físicamente 20 veces en su disco, mientras que en el caso
del 'crossposting' solo se envía y se guarda 1 vez. Por
esto el 'spam' es peor que el 'crossposting').
Además, en el caso del 'crossposting'
nuestros lectores de correo tratan el artículo como uno solo y
una vez leído no nos lo muestran en otros grupos (esto es cierto
sólo cuando clientes y servidores manejan correctamente la línea
"Xref:"), mientras que cuando se envía
independientemente nos los volvemos a encontrar una y otra vez.
Si es imprescindible enviar un artículo
a varios grupos, hazlo 'crossposted', no 'spammed'
pero, por favor, siguiendo las indicaciones de 5.4
El 'spam' no es exclusivo de
Usenet, le basta el correo electrónico. Hasta ahora, en España no
tenemos mucho problema con el 'spam' por 'e-mail',
pero todo se andará (el asunto está cada vez más caliente en
los USA). Pregúntate, por ejemplo, de donde sacan las empresas
"spameadoras" las direcciones electrónicas del público
probablemente interesado en tal o cual producto (Pista: piensa en
los posibles usos de los formularios existentes en muchas paginas
WEB. Ah ! Y ¿sabes lo que son las "cookies"?)
El 'spam' es perjudicial (más
que el 'crossposting') por el tiempo y el dinero que hace
perder a los usuarios, porque habitualmente se trata de basura y
porque normalmente los 'spammers' falsifican sus
direcciones.
Domènec
Sos desintoxica con una anécdota:
"El termino spam
(carne de cerdo picada con especias) y su uso en Usenet proviene
de un hilarante sketch de los Monty Python en que el
cliente de un restaurante se ve forzado a tomar spam en
cualquier plato que escoja, lo quiera o no (o spam con spam,
incluso spam y spam con spam, además de spam de spam
con spam y spam). Esta inevitabilidad y pesadez del spam
de los Monty es la que se asocia a los mensajes intrusos en
Usenet. Se puede leer el guión del sketch en http://www.ironworks.com/comedy/python/spam.htm,
incluyendo un spam.wav
con la canción del spam."
[ Contenido ]
7
- ¿Qué es 'ECP'? ¿Y 'EMP'? ¿Y el 'Índice
Breidbart' (BI)?
'EMP' significa 'Excesive
Multi-Posting', es decir, es lo mismo que 'spam':
demasiados envíos por separado del (sustancialmente) mismo artículo.
'ECP' significa 'Excesive
Cross-Posting', es decir, se refiere a las ocasiones cuando se
envían muchos mensajes a más de un grupo cada uno.
A menudo se aplica el término 'spam'
de modo genérico, esto es, tanto al EMP (el 'spam'
propiamente dicho) como al ECP.
Existe un amplio consenso en el
sentido de que el 'spam', en sentido genérico, constituye
un abuso y puede implicar LA CANCELACIÓN de los ARTÍCULOS
constitutivos de dicho 'spam'.
Seth Breidbart inventó una fórmula
(el 'índice Breidbart') que trata de cuantificar el grado de
'maldad' de un 'spam' en concreto (sea ECP o EMP).
Se define el Índice Breidbart como la suma de las raíces
cuadradas de 'n', siendo 'n' el número de 'newsgroups' al
que fue enviado un artículo.
Ejemplo: Si envías 2 copias del
mismo artículo, la primera a 9 grupos a la vez y la segunda a 16
a la vez, el BI es sqrt(9) + sqrt(16) = 7.
Un artículo puede ser CANCELADO
si:
-
Su BI es mayor o igual
que 20 considerando los últimos 45 días.
-
Es continuación de un EMP/ECP
previo.
[ Contenido ]
8
- ¿Qué es un grupo moderado?
Cuando un grupo es moderado los artículos
que se le envían no le llegan directamente, sino que son
previamente enviados a una dirección de 'e-mail' (este
proceso suele ser transparente para el usuario, a quien le parece
que envía el artículo a un grupo normal) , donde el moderador,
que puede ser un programa o una persona, lo recibe; el moderador
(también puede ser un grupo de moderadores) decide entonces si el
artículo es apropiado para el 'newsgroup' (en función de
la política de moderación que se siga en el grupo, establecida
en su proceso de creación). Si es adecuado,
lo "inyecta" en el 'newsgroup'; si no lo es, el
artículo es rechazado.
Como el artículo no se inyecta
directamente en Usenet, sino que se envía por 'e-mail' al
moderador, es normal que tarde más en aparecer en tu servidor:
primero, por el tiempo necesario para la moderación (desde que lo
envías hasta que el moderador lo aprueba y lo inyecta en las 'news');
segundo, porque tu artículo será inyectado en un servidor de 'news'
que no tiene por qué ser el tuyo, y pasará tiempo hasta que
tu servidor lo reciba.
Como se puede suponer, el propósito
de la moderación es evitar artículos inapropiados para el grupo.
Ejemplos: artículos cuya temática no tiene que ver con el grupo,
'crossposting', 'spam', artículos ofensivos...
Mucha gente entiende que los grupos
moderados, sobre todo en los grupos de la jerarquía soc.*, no son
más que una forma de censura. Personalmente me parece que Usenet
tenderá hacia la 'moderación suave' (contra 'crossposting'
y 'spam', principalmente) o tendrá graves problemas para
sobrevivir como la conocemos hasta ahora. De hecho, ya empieza a
suceder que la gente que busca utilidad y/o seriedad en Internet
se decanta por las listas de distribución de 'e-mail' en
detrimento de Usenet.
[ Contenido
]
8.1
- ¿Que es la robomoderación?
Muchas de las tareas
correspondientes a la moderación de un 'newsgroup' pueden
automatizarse completamente (por ejemplo, rechazar los artículos
'crossposteados' a mas de X 'newsgroups' o aquellos que
contengan archivos binarios); por tanto se puede aligerar el
trabajo de los moderadores utilizando un programa ("robomoderador")
que se encargue de realizar estas tareas de rutina.
El robomoderador estaría en
cualquier máquina con acceso a Internet (normalmente se tratará
de una máquina Unix). Los mensajes que enviáramos al grupo
robomoderado no irían directamente a un servidor de 'news',
sino que serían enviados a una dirección de correo electrónico
en dicha máquina. El programa robomoderador los recibiría allí
y decidiría cuáles rechazar y cuáles no (estos los enviaría a
continuación a un servidor de 'news'), y, en su caso, cuáles
redirigiría a un moderador humano para que decidiera él.
[ Contenido ]
8.2
- Con los 'killfiles' ¿puede conseguirse lo mismo que con
la moderación automática?
Esto no es del todo correcto. En
primer lugar, muchos usuarios de las 'news' las leen
utilizando programas que no incluyen 'killfiles'.
En segundo lugar, las consecuencias
en ambos casos son muy diferentes. Brad
Templeton (en news.software.readers)
dice:
"...la verdadera razón por
la que los 'killfiles' no son tan buena idea es que
fragmentan la red.
...eliminar los 'crossposts'
es muy sencillo, y mucha gente lo hace.
Pero lo que se consigue es tener
un grupo que algunos lectores perciben como tranquilo mientras
que a otros les parece sumamente ruidoso y acaban participando,
consciente o inconscientemente, en los hilos [masivamente]
cruzados. Mucha gente que no quiere utilizar 'killfiles'
simplemente participa menos o se va.
Un grupo de 'news' no es
un tema. Es, ante todo, un grupo de personas. Pero los 'killfiles',
si se convierten en imprescindibles, arruinan esto. El grupo se
fragmenta en diferentes conjuntos de personas y cada uno de
ellos tiene una visión distinta del 'newsgroup': de este
modo la comunidad desaparece. Si he sido un gran defensor de los
'killfiles' en los "viejos tiempos" es debido a
que entonces no eran muy necesarios. Hoy los necesitamos
demasiado, y el resultado no es tan bueno.
Pero lo principal es que si un
grupo de 'news', antes que un tema, debe ser un grupo,
entonces debe haber algún tipo de experiencia compartida. Es la
experiencia compartida lo que convierte el grupo en
comunidad."
[ Contenido ]
9
- ¿Qué es un 'troll'?
Un "troll", en
Usenet, no es la criatura monstruosa que sale en los libros de
Tolkien ;-) sino un artículo provocador que se envía a las 'news'
con la intención de producir una gran cantidad de respuestas frívolas.
La temática de los "trolls"
cae, generalmente, en las mismas áreas. Puede consistir en una
aparentemente absurda contradicción del sentido común, un insulto
deliberadamente ofensivo a los lectores de un 'newsgroup',
o una amplia petición de información trivial. Seguramente se
trata de un "troll" el mensaje que leas si tiene
pocas líneas y es de este estilo:
-
"Los PCs son mucho mejores
que los Mac"
-
"Los Mac son mucho mejores
que los PCs"
-
"¿Cómo se dice '...' en
tu idioma?
-
"Los (cualquier
nacionalidad, profesión, sexo, etc) son #@!!$",
"Inmigrantes fuera !!!"
-
Etc.
El resultado de estos artículos
es, frecuentemente, una riada de enfadadas respuestas. En algunos
casos (sobre todo si se combina con el 'cross-posting') el 'thread'
originado por un "troll" puede durar semanas.
Estos mensajes se envían a cientos, miles, de servidores de 'news'
por todo el mundo, malgastando así los recursos de la red y el
dinero de la gente que tiene que pagar para recibir las 'news'.
Este tipo de 'thrads' resulta frustrante para las personas
que tratan de tener conversaciones "con sustancia" en un
'newsgroup'.
La gente que envía "trolls"
lo hace para llamar la atención, fastidiar un 'newsgroup'
y liarla. La mejor respuesta a un "troll" es NO
RESPONDER; si haces un 'followup' a un "troll"
contribuyes a agrandar el efecto "bola de nieve" para
mayor divertimento del "troller". Debes tener
esto en cuenta antes de enviar cualquier respuesta.
Por favor, tratad los "trolls"
de modo constructivo, y no participéis en su juego. Ayudaréis a
que Usenet sea un lugar mucho más agradable para la conversación.
[ Contenido ]
10
- ¿Qué hay del envío de binarios a las 'news'?
Por archivos binarios se entienden
aquellos que contienen información no directamente comprensible
por las personas (textual), es decir: ejecutables (programas), imágenes
(.gif, .jpeg, .jpg,...), audio (.wav, .au, ...), vídeo (.mpeg, .mpg,
.avi, ...), etc.
Todos ellos tienen en común una
cosa: son grandes. Y esto tiene implicaciones en relación al uso
de recursos (espacio en el disco de los servidores y ancho de
banda ocupado para transmitirlo entre los servidores y de los
servidores a los clientes) en Usenet.
Es por esto que en Usenet es, desde
cualquier punto de vista, incorrecto enviar archivos
binarios a 'newsgroups' no específicamente dedicados a
ellos.
Los grupos de noticias dedicados al
intercambio de binarios fueron la solución en su día, cuando los
medios más apropiados para dicho intercambio (es decir, los
servidores FTP y la WEB) no estaban al alcance del usuario medio
(o ni siquiera existían). Pero hoy cualquier internauta tiene la
posibilidad (por cierto, gratuita) de utilizar al
menos la WEB para obtener archivos binarios o ponerlos a disposición
de los demás.
La opinión personal del autor es,
por tanto, que sólo en casos muy justificados debería utilizarse
Usenet para el trasiego de binarios. Y en tal caso, exclusivamente
en los grupos dedicados a ellos.
[ Contenido ]
11
- NoCeM: Usenet a la medida de cada usuario.
[N. del A.: Esta parte ha
sido adaptada de "The NoCeM FAQ", que se puede encontrar
en http://www.nocem.org/faq.html]
'Crossposting', 'spam',
binarios en grupos inadecuados, artículos fuera de tema, "trolls"...
y también cancelaciones, acusaciones de censura, etc; Usenet cada
día es más ruidosa, cada vez más gente abusa de Usenet y, por
tanto, cada vez más gente se convence de que la solución es
hacerla menos libre. No debe ser así.
Ya hemos visto (ver
8.2) una solución parcial: los "killfile" o
filtros de mensajes, que permiten a cada usuario, con sus lógicas
limitaciones, tener una visión parcial de Usenet, eliminando en
buena parte los artículos que no desea ver. Presentamos a
continuación otro sistema de adaptar Usenet a nuestros deseos
preservando la libertad en ella.
[ Contenido ]
11.1
- ¿Qué es NoCeM ?
NoCeM (pronúnciese "No
See'Em" (nou siem :-), literalmente "No
verlos") puede ser:
-
- Una solución al problema del 'spam'.
-
- Una solución al problema de la
cancelación del 'spam'.
-
- Un modo de "editar"
Usenet si eso es lo que deseas.
-
- Una forma de que otros
"editen" Usenet por ti, si así lo quieres.
-
- La solución para que nadie
altere lo que ves en Usenet (hasta donde es posible)
[ Contenido ]
11.2
- ¿Cómo funciona?
Hay tantas opiniones como personas
en cuanto a lo que se debería enviar a Usenet. Algunos tienen un
amplio apoyo, como los canceladores de 'spam'. Otros, como
los que desean censurar puntos de vista distintos de los suyos, no
tienen apoyo. Existen muchas situaciones entre ambos extremos.
Según el modelo de NoCeM,
cualquier persona que vea en Usenet algo que piensa que no debería
haberse enviado puede emitir un mensaje NoCeM ('NoCeM notice').
Sin embargo, como sucede con cualquier artículo en Usenet, la
importancia que los demás concedan a dicho mensaje NoCeM no será
mayor que la reputación de esa persona en la Red. Si la gente está
de acuerdo con los criterios de esta persona y piensan que es lo
suficientemente objetiva como para juzgar según esos criterio,
entonces puede que acepten sus mensajes NoCeM. Por supuesto, también
sucederá lo contrario: que no estén de acuerdo con sus criterio
o no la consideren un buen juez y por tanto no acepten sus
mensajes NoCeM.
Cuando alguien acepta un mensaje
NoCeM, se llevará a cabo una acción predeterminada. Lo más
frecuente es que se marque el artículo al que hace referencia
como leído en el fichero 'newsrc' de dicho usuario. Sin embargo,
también es posible configurarlo para que recupere el artículo al
que se refiere del servidor y lo marque como artículo en el que
el lector puede estar interesado (por ejemplo, si siempre lee los
artículos de determinada persona).
[N. del A.: nótese que el
administrador de un servidor de 'news' puede utilizar NoCeM
para identificar artículos que considere indeseados y
posteriormente cancelarlos o eliminarlos del servidor: como es su
máquina, puede hacer lo que quiera].
[ Contenido ]
11.3
- ¿Es posible que mi administrador (o el de algún servidor que
suministre artículos al mío) pueda utilizar NoCeM para censurar
lo que veo?
Una vez leído el apartado
anterior, la respuesta (obvia) es "Sí". Pero esto ha
sucedido siempre, el administrador de tu servidor y los de los
servidores que "alimentan" al tuyo siempre han podido
controlar lo que puedes y no puedes ver. Son sus máquinas, y
pueden hacer con ellas lo que quieran. Si no te gusta, debes
buscar otro servidor de 'news' que tenga una política
menos restrictiva en cuanto a contenidos.
[ Contenido ]
11.4
- ¿Se pueden falsificar los mensajes NoCeM ?
No, ya que los mensajes NoCeM deben
ir firmados mediante PGP. Cada usuario de NoCeM es responsable de
las claves públicas PGP que incluye en su archivo de claves y,
por tanto, es responsable de a quien da acceso.
[ Contenido ]
11.5
- ¿Qué tengo que hacer para recibir y utilizar los mensajes
NoCeM ?
Actualmente sólo existe un cliente
NoCeM para Unix, que se puede encontrar en http://www.nocem.org/nocem-0.93.tar.asc.
Como está escrito en Perl, la adaptación a MS-DOS es sencilla
(puedes encontrar una descripción buscando en Dejanews
el artículo titulado "NoCeM (the CancelMoose Perl Client)
on Windows systems", publicado en news.software.misc y
alt.nocem.policy en Diciembre del 97; si alguien lo quiere, que me
lo pida), aunque todavía no existe (que yo sepa) versión
"oficial" para MS-DOS.
Para utilizar NoCeM necesitarás,
además:
[ Contenido ]
12
- ¿Qué hay que saber sobre los lectores de 'news'?
De esta sección se espera una gran
utilidad práctica. Veremos primero, de un modo general, las
funcionalidades básicas que cabe pedir a un lector de 'news' y,
a continuación, pasaremos revista a alguno de los lectores más
usados.
[ Contenido ]
12.1
- Generalidades
Aunque cada lector tiene sus
peculiaridades, he aquí una breve descripción de lo que todos
permiten hacer:
1 - Conectar con un servidor de 'news'
Es lo primero que hará el lector
al arrancar. Si es la primera vez que se conecta a ese servidor en
concreto, se bajará la lista de todos los grupos contenidos en
dicho servidor, lo que tardará unos minutos; si no es la primera
vez, lo normal es que se baje el número de artículos (total y
sin leer) de cada grupo al que estés suscrito.
2 - Leer un 'newsgroup'
Tu lector, después del paso
anterior, te mostrará la lista de los 'newsgroups' a los
que estás suscrito y/o la lista de todos los 'newsgroups'
del servidor al que estás conectado. En cualquier caso, podrás
seleccionar un 'newsgroup' para que tu lector se baje del
servidor las cabeceras de sus artículos (Sólo los artículos sin
leer o todos los artículos, leídos y sin leer, según
como tengas configurado tu lector). Una vez hecho esto, podrás
seleccionar el artículo que deseas leer, tras lo cual tu lector
se bajará del servidor el cuerpo de dicho artículo y te lo
mostrará.
La mayoría de los lectores
permiten ordenar la lista de artículos por fecha, por 'Subject:',
por autor y por 'thread'.
ATENCIÓN: normalmente, cuando leas
un artículo éste quedará marcado como leído, de manera
que, si tienes configurado tu lector para que te muestre sólo los
artículos sin leer, la próxima vez que entres en el mismo grupo no
verás dicho artículo. Si quieres volverlo a ver tendrás que
reconfigurar el lector para que muestre todos los artículos
(leídos y sin leer). Ten en cuenta también que, normalmente, tu
lector no bajará todos los artículos de un 'newsgroup'
(ya que puede haber muchos y tardaría demasiado), sino que está
configurado para bajarse los X artículos más recientes. Si
sigues sin ver un artículo que habías visto anteriormente es
posible que sea más antiguo que los X artículos que te muestra.
Algunos lectores permiten que se les pida que bajen más artículos
o que se bajen todos. Si no, quizá puedas reconfigurar tu lector
para que se baje un número más grande de artículos.
3 - Contestar a un artículo
Tras leer un artículo puede que
desees contestarlo. Para ello, probablemente tu lector, además de
componer tu respuesta, te permitirá estas 3 opciones:
a. Enviar la respuesta a las 'news'
('followup')
b. Enviar la respuesta por e-mail al autor del artículo al
que respondes.
c. Las 2 anteriores simultáneamente.
[Antes de responder a un artículo
por primera vez, lee las secciones 3.2, 3.3,
3.4, 4 y 5.
Son MUY IMPORTANTES]
4 - Enviar un artículo
Está claro, ¿no? ;-)
5 - Edición de cabeceras al
componer artículos
Asegúrate de aprender pronto
cómo se hace esto en tu lector; antes de enviar cualquier artículo
deberás comprobar las cabeceras, y, si es necesario, modificar
las correspondientes a 'Followup-To', 'Reply-To:',
etc, como se ha mencionado anteriormente.
4 - Gestión de 'newsgroups'
a. Suscripción / Cancelación de
Suscripciones
b. Ver si se han creado grupos nuevos
[ Contenido ]
12.2
- Un lector 'off-line': Forte Free Agent
Escrito por Pedro
Macanás Valverde y Fran
Bernal Fernández.
12.2.1
- Clases de lectores. Datos básicos.
Llega el gran momento. Nos hemos
decido a participar en lo que se denomina la conciencia o estado
de opinión de Internet ( "Usenet", "news"
o noticias), pero debemos elegir el vehículo adecuado. ¿Por cuál
decidirnos?
Sin lugar a dudas, para la mayoría
de los usuarios la mejor elección será un programa de noticias
extralineado ('offline'). A diferencia de los enlineados ('online'),
pueden guardar los encabezados de los artículos (título y autor)
cuando el usuario esté conectado, elegir con el teléfono colgado
los que más le interesen y posteriormente conectar a fin de
guardar en el disco duro el contenido (cuerpo) de los artículos
elegidos (por lo que no necesitará estar conectado para leerlos,
con el consiguiente ahorro telefónico).
Para explicar el funcionamiento de
dichos programas utilizaremos Forte Free Agent, que es
gratuito y se puede encontrar en http://www.forteinc.com/.
Para resolver las dudas que nos surjan podemos acudir a news:alt.usenet.offline-reader.forte-agent.
Al poner el ratón sobre los
botones del programa, nos aparecen unas pistas (letreros
amarillos) con el nombre de los mismos y que nos serán de gran
ayuda.
Para que nuestro programa de news
pueda funcionar, deberemos proporcionarle algunos datos:
a) Relativos al servidor. Entrando
en el menú Options-General Preferences-System deberemos
indicar como:
-
'News server': el que nos
haya indicado nuestro proveedor de Internet (el nombre del
servidor seguramente comenzara por nntp., news. o noticias. ).
-
'Email' (correo electrónico): el que nos haya indicado nuestro proveedor
(seguramente comenzará por smtp. , mail. o ecorreo.).
-
'Time zone' = GMT+1 (España).
b) Relativos al usuario y otros
datos:
-
'Email': vuestro
identificativo@dominio.
-
'Full name': nombre de
pila y apellido(s). También podemos añadir otros datos como
sexo ( :-# para varón y :-{} para mujer) pudiendo ir seguido
de un número, que indica la edad.
-
'Language': pulsar 'add'
y añadir 'castellano'.
12.2.2
- Suscripción a los grupos existentes y obtención de otros
nuevos.
El programa Free Agent cuenta con
tres ventanas:
a) Grupos o foros (subscritos,
todos -'all'- o nuevos -'new'- ).
b) Artículos, 'news' o 'postings':
en el que muestras el estado de los mismos (ej. leídos o no), el
tema ('subject') y los datos del autor.
c) El contenido del artículo.
Nuestra atención se centrará
ahora en la primera de ellas (la de Grupos ). Yendo a Group-show-all
podremos ver los distintos grupos, por ejemplo, news:alt.comp.periphs.dcameras
(sobre cámaras digitales), news:alt.comp.periphs.multifunctions
(trata de los equipos multifuncionales), news:alt.culture.us.hispanics
(los hispanos de EE.UU.), news:soc.culture.esperanto,
etc... (los que empiezan por es. son los españoles).
Podemos buscar cualquier grupo por
su nombre pulsando sobre el primer icono de linterna, repitiendo
la búsqueda con el segundo icono hasta encontrar el foro deseado.
Para subscribirnos a un grupo,
debemos seleccionarlo (hacer clic -utilizando el botón
izqdo. del ratón- sobre su nombre) y pulsar sobre el icono 'subscribe'
(que tiene la apariencia de un periódico).
Periódicamente podemos ver los
grupos nuevos que se creen yendo a al menú de enlineación (Online-Get
New Groups ), pudiendo verlos con Group-show-New Groups.
12.2.3-
Lectura de artículos.
Nuestra atención se centrará ahora
en la segunda ventana, una vez que nos hayamos subscrito a un
grupo que nos pueda interesar.
Lo primero de todo es obtener los
encabezados (título y autor) de los nuevos artículos que se
hayan enviado al grupo últimamente. Para ello pulsaremos sobre el
primer botón (Get New Headers in Subscribed Groups),
estando conectados a Internet.
Los que llevan Re: son una contestación
a un artículo inicial que se llama igual que su
contestación (lo que se denomina respuesta o 'follow-up').
El artículo inicial y las respuestas forman un hilo ('thread').
Tras esto, podemos desconectarnos,
especialmente si estamos subscritos a muchos grupos. Cuando veamos
un artículo interesante, lo seleccionaremos y pulsaremos sobre el
botón 'mark for retrieval' ('marcar para recuperar' el
cuerpo o contenido del artículo).
Para obtener los cuerpos de los artículos,
debemos conectarnos de nuevo y pulsar el botón 'Get Marked
Message Bodies', tras lo cual podremos desconectarnos
definitivamente para leer los artículos con tranquilidad y con el
teléfono apagado.
También podemos decidir el
recuperar directamente todos los cuerpos de los artículos de un
grupo determinado que nos interese bastante (debemos tener en
cuenta que si son muchos grupos o el grupo tiene mucha actividad,
el lector tardará bastante en concluir su tarea). Para ello,
deberemos seleccionar dicho grupo, ir a Group-properties y
marcar override default settings-retrieve bodies for all new
messages.
Para leer los nuevos artículos de
un grupo (cuyo titulo aparecerá en rojo , debemos pulsar el botón
view next unread message. Si el artículo lleva anexado un
fichero binario (ej., una imagen), podemos utilizar el
decodificador "uudecode" de Agent, pulsando sobre el
icono Launch Binary Attachments.
12.2.4.
Llega el gran momento. Escribiendo artículos.
Iniciaremos nuestro bautismo electrónico
por los grupos a los cuales se pueden enviar artículos de pruebas
(test). Algunos de ellos son news:alt.test
, news:alt.binaries.test
(para fotografías, música, etc...), news:misc.test.
Para ello, seleccionaremos uno de
dichos grupos (por ejemplo, news:alt.binaries.test
) y pulsaremos sobre el botón Post New Usenet Message
(enviar nuevos artículo de Usenet). Deberemos ponerle título (subject),
un contenido (como puede ser un saludo y añadirle un fichero
binario - por ejemplo una foto - pulsando sobre Attachment)
y, si lo deseamos, un fichero de texto con nuestra firma (Signature,
que deberemos haber especificado en Options-Signatures-Add).
Podemos elegir entre enviarlo después,
cuando estemos conectados (send Later) o enviarlo ahora (send
Now).
También podemos enviar un nuevo
mensaje de correo (post new email message). La diferencia
entre un mensaje usenet y un mensaje de correo, radica
principalmente en que el primero es enviado al grupo y es público
(se puede leer por todo el mundo que vaya al grupo, como un tablón
de anuncios), mientras que el segundo se envía directamente al
buzón del destinatario y es privado . Se puede enviar, por
ejemplo, un nuevo mensaje de correo cuando vemos en un artículo
una dirección de correo interesante, que no es la del remitente.
Las diferentes formas de respuesta
(Re:) a un artículo son:
a) Respuesta o 'follow-up'
(artículo -público- de Usenet).
b) Réplica o reply ( carta
- privada - de correo electrónico).
Cada una de dichas respuestas tiene
su propio botón y para utilizarlo, primero deberemos seleccionar
el artículo que deseamos contestar.
Podemos internacionalizar nuestras
respuesta yendo a Options-Posting Preferences- General -
Introductions y poniendo "Je la " delante de %date%,
"en" delante de %newsgroups% y "skribis:"
delante de /n .
12.2.5-
Envío y purga de los artículos.
Para enviar los artículos (y, en
su caso, cartas) que hayamos escrito, deberemos conectarnos a
Internet e ir al menú Online
(enlineacion)-Post Usenet and Email Messages.
Una vez enviados, se puede
comprobar que han llegado correctamente, yendo al menú Window-Open
Outbox . Si aparece un icono amarillo con una cara sonriente,
el envió se ha realizado correctamente. Si el icono es rojo, ha
surgido algún problema (aunque existe una única situación en la
que el artículo se mandado correctamente y se muestra una cara
roja - cuando se ha enviado a un grupo moderado; para solucionar
este problema se ha propuesto el que aparezca un icono con la
imagen de un pequeño pantano, representando la contención que
existe en dichos grupos).
Podemos observar nuestro artículo,
seleccionando el grupo al que los hayamos enviado, pulsando sobre
el botón Get New Headers in Selected Groups, seleccionando
el encabezado de nuestro artículo y pulsando Get selected
Message Bodies.
Para ver el hilo de las respuestas
que el mismo vaya suscitando, deberemos seleccionar el mensaje y
pulsar sobre el botón Watch Thread. Y al contrario, si
existe un hilo que no tenemos el más mínimo interés en seguir,
deberemos pulsar sobre el botón Ignore Thread.
Cuando el número de encabezados o
cuerpos de los artículos comienza a ser excesivo, se puede
utilizar la función de purgar, de forma que sólo queden
guardados los más recientes.
En cualquier caso, si tenemos
especial interés en guardar un artículo, deberemos seleccionarlo
y pulsar sobre el botón Keep Message.
[ Contenido ]
13
- ¿Dónde puedo encontrar un artículo que leí hace meses (y no
recuerdo bien en qué grupo)?
Existen repositorios de artículos;
el más conocido de ellos es DejaNews (http://www.dejanews.com/)(Google.com).
Ofrece potentes facilidades de búsqueda de artículos y puede
resultar muy útil.
Esto quiere decir que los artículos
que escribimos quedan registrados en los repositorios como
DejaNews; sin embargo, si entiendes dicho registro como un
atentado a tu intimidad, en el caso de DejaNews puedes evitarlo
incluyendo "x-no-archive: yes" en las cabeceras de tus
artículos, si tu programa de 'news' te lo permite, o en la
primera línea del cuerpo del mensaje, en caso contrario.
[ Contenido ]
14
- ¿Existe alguna página Web donde aparezcan los grupos de
'news' extranjeros?
Contesta Alain
Deckers:
"Es casi imposible obtener
una relación de todos los grupos extranjeros que se han
creado por todo el mundo, ya que hay decenas de miles y no todas
las jerarquías son propagadas fuera de su ámbito geográfico.
Si te refieres a los grupos de
las 8 principales jerarquías (las llamadas Big8), es
decir: comp.*, humanities.*, misc.*, news.*, rec.*, sci.*, soc.*
y talk.*, lo mejor que puedes hacer es utilizar un servicio como
DejaNews (ahora en
Google.com).
[ Contenido ]
15
- ¿Dónde puedo encontrar mas información?
GENERAL:
MIME
NETIQUETA:
MODERACIÓN:
'CROSSPOSTING'
Y 'SPAM':
[ Contenido ]
