Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
Los módulos SMTP (Simple Mail Transfer Protocol) [RFC821] y POP3 (Post Office Protocol - Versión 3) [RFC1725] proporcionan, sin duda, uno de los servicios más antiguos, difundidos y útiles del mundo TCP/IP: el correo electrónico.
Tradicionalmente el correo electrónico entendido como el intercambio de mensajes textuales en ASCII se estandarizó en el mundo TCP/IP en [RFC821] y [RFC822] que definen, respectivamente, el protocolo de transferencia de correo SMTP y el formato de cabecera de los mensajes. Este protocolo sencillo ha sido ampliado considerablemente. En la actualidad el protocolo SMTP ha experimentado numerosas extensiones [RFC1652] [RFC1830] [RFC1845] [RFC1846] [RFC1854] [RFC1869] [RFC1870] [RFC1891], todas ellas compatibles con el estándar primitivo e interoperantes. Asimismo el propio formato de los mensajes ha sufrido una considerable ampliación gracias al MIME (Multipurpose Internet Mail Extensions) [RFC1521] [RFC1522], facilitando el intercambio de mensajes en lengua no inglesa y conteniendo gráficos, sonidos y demás elementos multimedia.
El SMTP clásico considera que los ordenadores que constituyen la red (o, al menos los ordenadores que forman parte de la red de correo electrónico) están permanentemente accesibles. Ello resultaba asumible en el mundo de los grandes mainframes pero en la actualidad, sobre todo debido al crecimiento espectacular de las empresas proveedoras de acceso a Internet, la mayor parte de los usuarios permanecen largos lapsos de tiempo desconectados del sistema. Periódicamente (por ejemplo, una vez al día) realizan un acceso por MODEM a su proveedor para revisar el correo, enviar mensajes pendientes y actualizar su base de mensajes NEWS [RFC977] [RFC1036], por ejemplo. Ello hace necesario el desarrollo de un nuevo protocolo de correo electrónico, conocido como POP3 (Post Office Protocol - versión 3) [RFC1082] [RFC1725] [RFC1734]. Existen otros sistemas propietarios, como el PCMail [RFC993], pero POP3 es el más difundido en la actualidad. Con SMTP se envían los mensajes, mientras que POP3 se emplea para recibirlos.
Con el enorme crecimiento comercial y privado experimentado en Internet en los últimos años, se ha hecho un esfuerzo considerable en aumentar la seguridad del correo electrónico mediante servicios de privacidad y autenticidad como los definidos en PEM (Privacy Enhanced Mail) [RFC1421] [RFC1422] [RFC1423] [RFC1424] y en diversas extensiones MIME [RFC1847] [RFC1848]. De todos modos, hasta donde sabe el autor, el método más difundido de proporcionar dichos servicios es mediante el empleo del software criptográfico PGP (Pretty Good Privacy).
Por otra parte se advierte una tendencia a unificar los sistemas de correo electrónico del mundo Internet y del mundo OSI, como la atestigua el gran número de RFC's publicados sobre el particular [RFC1664] [RFC1495] [RFC1496] (y otros). El hecho de que Internet se haya difundido con gran rapidez en nuevos paises de habla no inglesa ha impulsado también el desarollo de nuevos avances [RFC1456] [RFC1468] [RFC1556] [RFC1641] [RFC1815] [RFC1842] [RFC1843].
Recientemente se ha definido un nuevo protocolo de correo
electrónico que, en cierto modo, fusiona el SMTP y el POP3. Se
trata de IMAP4 (Internet Message Access Protocol -
Versión 4)
[RFC1730]. Se trata de un esquema bastante complicado y con unas
facilidades actualmente subutilizadas, por lo que se ha
considerado preferible no implementarlo.
Interfaz
La interfaz de este módulo está constituida por diversos procesos cooperantes y varias rutinas que se ejecutan en el contexto del llamante. Es importante recordar que la capa SMTP se emplea a la hora de enviar los mensajes electrónicos, mientras que es el nivel POP3 el utilizado para recibirlos.
PROC_SMTP_BC PROC_POP3_BC
Estos procesos son los encargados de inicializar los módulos. Deben ser invocados con un mensaje "MSG_INIT" o "MSG_QUIT". La inicialización de estos módulos debe ser posterior a la del módulo TCP.
PROC_SMTP_SUP PROC_POP3_SUP
Estos procesos son los encargados de recibir los comandos provenientes de la capa superior y efectuar las tareas demandadas. Los mensajes que esperan recibir son "MSG_MBUF", con el siguiente formato:
campo1: Cadena de MBUF's conteniendo el comando a ejecutar y
todos sus parámetros. El comando y los parámetros deben
ir, cada uno de ellos, en un nodo de la cadena.
campo2: Identificador de la conexión
campo3: No utilizado
Las capas SMTP/POP3 intentarán ejecutar el comando solicitado, con los parámetros que se indiquen. La realimentación que se genera es puramente visual. Cuando estos módulos desean informar de algo al usuario envían un mensaje "MSG_MBUF" a la capa superior, con el formato habitual:
campo1: Cadena de MBUF's conteniendo el mensaje a visualizar
campo2: Identificador de la conexión
campo3: Indeterminado
Como regla general, para que el usuario pueda distinguir los mensajes textuales de las capas SMTP/POP3 de los enviados por el servidor, los primeros van precedidos por tres asteriscos ("***").
Si el usuario desea abortar la ejecución de un comando SMTP/POP3, genera un mensaje "MSG_SMTP_ABORT" o "MSG_POP3_ABORT" con el formato:
campo1: Indeterminado
campo2: Identificador de la conexión
campo3: Indeterminado
La realimentación, nuevamente, será visual.
Los comandos actualmente implementados para la capa SMTP, son:
Este comando debe ser el primero que enviamos cuando se abre una conexión SMTP, en respuesta al mensaje de bienvenida del servidor. Requiere un parámetro, que será el nombre jerárquico que identifica nuestra máquina.
Este comando es equivalente al anterior (y con el mismo parámetro), pero comprueba si el servidor es un servidor SMTP de segunda generación. Ello da pie a utilizar servicios extendidos. Para más información consultar [RFC1869]. Si se trata de un servidor de primera generación, el comando "EHLO" no será reconocido y tendremos que identificarnos mediante "HELO".
Este comando permite cambiar el directorio de trabajo para el módulo SMTP. En el directorio de trabajo se encuentran los mensajes que deseamos transmitir.
Este comando interpreta su parámetro como el nombre de un fichero que contiene una serie de mensajes con el formato definido en [RFC822]. Según ello analizará sus cabeceras Internet intentando localizar las direcciones de los destinatarios y del remitente, y enviará el mensaje a través del servidor al cual estamos conectados. Se muestra en pantalla toda la operación de transferencia.
Este comando no requiere parámetros y sirve para cerrar una conexión SMTP. Si el servidor se niega a hacerlo puede clausurarse el enlace de forma imperativa mediante una rutina definida más adelante.
Cuando la conexión se cierra se envía un mensaje "MSG_SMTP_CLOSE" con el formato:
campo1: Ignorado
campo2: Identificador de la conexión
campo3: Ignorado
Los comandos actualmente existentes para la capa POP3, son:
El parámetro especificado proporciona el nombre de usuario bajo el cual nos conoce el servidor.
Este comando debe seguir inmediatamente al comando "USER" y su parámetro será la palabra clave que le corresponda.
Este comando permite cambiar el directorio de trabajo para el módulo POP3. En el directorio de trabajo se almacenarán los mensajes que se reciban.
Este comando pide a la capa POP3 que recoja todo el correo pendiente y lo almacene en el fichero especificado como parámetro. Los mensajes se almacenan en formato MAILBOX: todos los mensajes empiezan por una línea "FROM" y entre mensaje y mensaje se almacena una línea en blanco.
Los mensajes recibidos son borrados del servidor de forma automática.
Este comando no requiere parámetros y sirve para cerrar una conexión POP3. Si el servidor se niega a hacerlo puede clausurarse la conexión de forma imperativa mediante una rutina definida más adelante.
Cuando la conexión se cierra se envía un mensaje "MSG_POP3_CLOSE" con el formato:
campo1: Ignorado
campo2: Identificador de la conexión
campo3: Ignorado
PROC_SMTP_INF PROC_POP3_INF
Estos procesos son los encargados de gestionar la recepción y el envío de mensajes electrónicos, y la información de control asociada. En general no tienen otra interacción con el usuario que la indicación de textos para ser impresos. No obstante también se encarga de informar de la apertura y cierre de enlaces SMTP/POP3.
Con estos mensajes se pretende que la capa superior imprima en la pantalla el texto indicado.
campo1: Cadena de MBUF's conteniendo el mensaje a visualizar
campo2: Identificador de la conexión
campo3: Indeterminado
Estos mensajes se generan para indicar a la capa superior que ha sido aceptado un intento de conexión SMTP/POP3 a una máquina remota. A partir de ese momento la conexión está abierta y lista para aceptar comandos. Si se trata de una conexión SMTP el primer paso será enviar un comando "HELO" o "EHLO". En el caso de POP3 será "USER" y "PASS".
campo1: Valor indeterminado
campo2: Identificador de la conexión
campo3: Valor indeterminado
Estos mensajes se generan cuando uno de los extremos cierra la conexión, ya sea mediante el comando correspondiente o gracias a una de las llamadas imperativas descrita a continuación.
campo1: Valor indeterminado
campo2: Identificador de la conexión
campo3: Valor indeterminado
En cuanto a las rutinas, su prototipos son:
void smtp_open(uint32 ip,uint16 puerto,uint32 id,proc_id proc_retorno); void pop3_open(uint32 ip,uint16 puerto,uint32 id,proc_id proc_retorno);
Estas rutinas intentan realizar una conexión SMTP/POP3 al puerto 'puerto' de la máquina 'ip'. 'id' contiene el identificador de la conexión y 'proc_retorno' es el proceso que debe ser informado de todos los eventos y que recibe los mensajes a imprimir. Como resultado de esta llamada, el proceso especificado recibirá un mensaje "MSG_SMTP_OPEN", "MSG_POP3_OPEN", o bien un "MSG_SMTP_CLOSE" o "MSG_POP3_CLOSE", según corresponda. Su formato será el declarado con anterioridad.
Aunque estas llamadas permiten abrir conexiones a cualquier puerto, el puerto por defecto asignado para SMTP es "SMTP_PUERTO" (puerto 25) y el asignado para POP3 es "POP3_PUERTO" (puerto 110).
void smtp_close(uint32 id); void pop3_close(uint32 id);
Estas rutinas cierran una conexión, especificada según su identificador 'id'. El proceso responsable recibirá un "MSG_SMTP_CLOSE" o "MSG_POP3_CLOSE", con el formato habitual, cuando la conexión se cierre finalmente. Esta orden no puede ser ignorada por el servidor, que se verá forzado a aceptar la desconexión.
estado smtp_flujo(uint32 id); estado pop3_flujo(uint32 id);
Estas rutinas informan de la disponibilidad de las capas SMTP/POP3 para aceptar nuevos comandos. La rutina devuelve "FLUJO_LLENO" si no puede hacerse cargo de comandos adicionales, y "OK" si admite nuevas peticiones. Dada la semántica implantada, si se envían comandos cuando el control de flujo está cerrado se mantendrán en una cola de espera. Adicionalmente se garantiza que si en un momento dado el control de flujo está abierto, éste permanecerá en dicho estado hasta que se envíe un nuevo comando. La utilidad de una función así consiste en la ejecución de ficheros "script" por parte del módulo principal.
'id' es el identificador de conexión sobre la cual estamos
solicitando información. Si en un momento dado el control de
flujo está cerrado habrá que reintentarlo de nuevo tras un
tiempo prudencial (por ejemplo, una décima de segundo).
Implementación
La implantación de los módulos SMTP y POP3 sigue de forma rigurosa las definiciones dadas en [RFC821] y [RFC1725]. Para que los procesos responsables de la transmisión de mensajes funcionen de forma adecuada necesitan que los mensajes propiamente dichos les proporcionen información sobre los destinatarios y remitentes de los mismos, según el formato [RFC822]. Dado que los módulos no realizan ningún otro procesado adicional sobre ellos, éstos pueden consistir en segmentos MIME [RFC1521] [RFC1522], siempre y cuando no se violen los principios de [RFC821] (en especial lo referente a la longitud de las líneas y al empleo de caracteres de ocho bits). Aún cuando se han definido ampliaciones del SMTP para facilitar el intercambio de información no textual entre máquinas remotas [RFC1869] (y otros) y a pesar de que el módulo implementado soporta la extensión "EHLO", no se ha contemplado, de momento, su implantación completa.
En cuanto al POP3, el mecanismo de autentificación empleado
implica la transmisión en claro de una clave. En un futuro se
plantea implantar la extensión POP3 "AUTH" [RFC1734] para evitar
este fallo de seguridad. De momento ello no ha sido posible porque
el servidor POP3 empleado para efectuar las pruebas no soporta
dicha funcionalidad.
Bibliografía
[RFC793] RFC793: "Transport Control Protocol"
Jon Postel
Septiembre 1.981
[RFC805] RFC805: "Computer Mail Meeting Notes"
Jon Postel
Febrero 1.982
[RFC821] RFC821: "SIMPLE MAIL TRANSFER PROTOCOL"
Jonathan B. Postel
Agosto 1.982
[RFC822] RFC822: "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES"
David H. Crocker
Agosto 1.982
[RFC876] RFC876: "Survey of SMTP Implementations"
D. Smallberg
Septiembre 1.983
[RFC974] RFC974: "MAIL ROUTING AND THE DOMAIN SYSTEM"
Craig Partridge
Enero 1.986
[RFC976] RFC976: "UUCP Mail Interchange Format Standard"
Mark. R. Horton
Febrero 1.986
[RFC977] RFC977: "Network News Transfer Protocol. A Proposed
Standard for the Stream-Based Transmission of News"
Brian Kantor
Phil Lapsley
Febrero 1.986
[RFC993] RFC993: "PCMAIL: A Distributed Mail System for
Personal Computers"
David D. Clark
Mark L. Lambert
Diciembre 1.986
[RFC1036] RFC1036: "Standard for Interchange of USENET Messages"
Mark Horton
R. Adams
Diciembre 1.987
[RFC1040] RFC1040: "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encipherment and Authentication
Procedures"
John Linn
Enero 1.988
[RFC1047] RFC1047: "DUPLICATE MESSAGES AND SMTP"
Craig Partridge
Febrero 1.988
[RFC1082] RFC1082: "Post Office Protocol - Version 3. Extended
Service Offerings"
Marshall Rose
Noviembre 1.988
[RFC1090] RFC1090: "SMTP on X.25"
Robert Ullmann
Febrero 1.989
[RFC1123] RFC1123:"Requirements for Internet Hosts --
Application and Support"
Robert Braden
Octubre 1.989
[RFC1137] RFC1137: "Mapping Between Full RFC 822 and RFC 822
with Restricted Encoding"
Steve Kille
Diciembre 1.989
[RFC1176] RFC1176: "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION
2"
Mark R. Crispin
Agosto 1.990
[RFC1203] RFC1203: "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION
3"
James Rice
Febrero 1.991
[RFC1211] RFC1211: "Problems with the Maintenance of Large
Mailing Lists"
Ann Westine
Jon Postel
Marzo 1.991
[RFC1327] RFC1327: "Mapping between X.400(1988) / ISO 10021 and
RFC 822"
Steve Hardcastle-Kille
Mayo 1.992
[RFC1343] RFC1343: "A User Agent Configuration Mechanism For
Multimedia Mail Format Information"
Nathaniel S. Borenstein
Junio 1.992
[RFC1344] RFC1344: "Implications of MIME for Internet Mail Gateways"
Nathaniel S. Borenstein
Junio 1.992
[RFC1421] RFC1421: "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures"
John Linn
Febrero 1.993
[RFC1422] RFC1422: "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management"
Steve Kent
Febrero 1.993
[RFC1423] RFC1423: "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers"
David Balenson
Febrero 1.993
[RFC1424] RFC1424: "Privacy Enhancement for Internet Electronic
Mail: Part IV: Key Certification and Related Services"
Burton S. Kaliski, Jr.
Febrero 1.993
[RFC1428] RFC1428: "Transition of Internet Mail from Just-Send-8
to 8bit-SMTP/MIME"
Greg Vaudreuil
Febrero 1.993
[RFC1429] RFC1429: "Listserv Distribute Protocol"
Eric Thomas
Febrero 1.993
[RFC1456] RFC1456: "Conventions for Encoding the Vietnamese
Language VISCII: VIetnamese Standard Code for
Information Interchange VIQR: VIetnamese
Quoted-Readable Specification Revision 1.1"
Cuong T. Nguyen
Hoc D. Ngo
Cuong M. Bui
Thanh van Nguyen
Mayo 1.993
[RFC1468] RFC1468: "Japanese Character Encoding for Internet
Messages"
Jun Murai
Mark Crispin
Erik M. van der Poel
Junio 1.993
[RFC1480] RFC1480: "Registration of a Cyrillic Character Set"
Andrew A. Chernov
Julio 1.993
[RFC1494] RFC1494: "Equivalences between 1988 X.400 and RFC-822
Message Bodies"
Steven J. Thompson
Harald Tveit Alvestrand
Agosto 1.993
[RFC1495] RFC1495: "Mapping between X.400 and RFC-822 Message
Bodies"
Harald Tveit Alvestrand
Steve Kille
Robert S. Miles
Marshall T. Rose
Steven J. Thompson
Agosto 1.993
[RFC1496] RFC1496: "Rules for Downgrading Messages from X.400/88
to X.400/84 When MIME Content-Types are Present in the
Messages"
Harald Tveit Alvestrand
Kevin E. Jordan, ARH215
James A. Romaguera
Agosto 1.993
[RFC1505] RFC1505: "Encoding Header Field for Internet Messages"
Albert K. Costanzo
David Robinson
Robert Ullmann
Agosto 1.993
[RFC1521] RFC1521: "MIME (Multipurpose Internet Mail Extensions)
Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies"
Nathaniel S. Borenstein
Ned Freed
Septiembre 1.993
[RFC1522] RFC1522: "MIME (Multipurpose Internet Mail Extensions)
Part Two: Message Header Extensions for Non-ASCII
Text"
Keith Moore
Septiembre 1.993
[RFC1523] RFC1523: "The text/enriched MIME Content-type"
Nathaniel S. Borenstein
Septiembre 1.993
[RFC1524] RFC1524: "A User Agent Configuration Mechanism For
Multimedia Mail Format Information"
Nathaniel S. Borenstein
Septiembre 1.993
[RFC1554] RFC1554: "ISO-2022-JP-2: Multilingual Extension of
ISO-2022-JP"
Masataka Ohta
Ken'ichi Handa
Diciembre 1.993
[RFC1556] RFC1556: "Handling of Bi-directional Texts in MIME"
Hank Nussbacher
Diciembre 1.993
[RFC1557] RFC1557: "Korean Character Encoding for Internet
Messages"
Hyunje Park
Kilnam Chon
Uhhyung Choi
Diciembre 1.993
[RFC1590] RFC1590: "Media Type Registration Procedure"
Jon Postel
Marzo 1.994
[RFC1641] RFC1641: "Using Unicode with MIME"
David Goldsmith
Mark Davis
Julio 1.994
[RFC1642] RFC1642: "UTF-7: A Mail-Safe Transformation Format of
Unicode"
David Goldsmith
Mark Davis
Julio 1.994
[RFC1652] RFC1652: "SMTP Service Extension for
8bit-MIMEtransport"
John Klensin
Ned Freed
Marshall T. Rose
Einar A. Stefferud
Dave Crocker
Julio 1.994
[RFC1664] RFC1664: "Using the Internet DNS to Distribute RFC1327
Mail Address Mapping Tables"
Claudio Allocchio
Antonio Blasco Bonito
Bruce Cole
Silvia Giordano
Robert Hagens
Agosto 1.994
[RFC1725] RFC1725: "Post Office Protocol - Version 3"
John G. Myers
Marshall T. Rose
Noviembre 1.994
[RFC1730] RFC1730: "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4"
Mark R. Crispin
Diciembre 1.994
[RFC1731] RFC1731: "IMAP4 Authentication Mechanisms"
John G. Myers
Diciembre 1.994
[RFC1732] RFC1732: "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
Mark R. Crispin
Diciembre 1.994
[RFC1734] RFC1734: "POP3 AUTHentication command"
John G. Myers
Diciembre 1.994
[RFC1740] RFC1740: "MIME Encapsulation of Macintosh files -
MacMIME"
Patrik Faltstrom
Dave Crocker
Erik E. Fair
Diciembre 1.994
[RFC1741] RFC1741: "MIME Content Type for BinHex Encoded Files"
Patrik Faltstrom
Dave Crocker
Erik E. Fair
Diciembre 1.994
[RFC1767] RFC1767: "MIME Encapsulation of EDI Objects"
David H. Crocker
Marzo 1.995
[RFC1806] RFC1806: "Communicating Presentation Information in
Internet Messages: The Content-Disposition Header"
Rens Troost
Steve Dorner
Junio 1.995
[RFC1815] RFC1815: "Character Sets ISO-10646 and ISO-10646-J-1"
Masataka Ohta
Julio 1.995
[RFC1830] RFC1830: "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages"
Gregory M. Vaudreuil
Agosto 1.995
[RFC1842] RFC1842: "ASCII Printable Characters-Based Chinese
Character Encoding for Internet Messages"
Ya-Gui Wei
Yun Fei Zhang
Jian Q. Li
Jian Ding
Yuan Jiang
Agosto 1.995
[RFC1843] RFC1843: "HZ - A Data Format for Exchanging Files of
Arbitrarily Mixed Chinese and ASCII characters"
Fung Fung Lee
Agosto 1.995
[RFC1844] RFC1844: "Multimedia E-mail (MIME) User Agent
checklist"
Erik Huizer
Agosto 1.995
[RFC1845] RFC1845: "SMTP Service Extension for
Checkpoint/Restart"
Dave Crocker
Ned Freed
A. Cargille
Septiembre 1.995
[RFC1846] RFC1846: "SMTP 521 Reply Code"
Alain Durand
Francis Dupont
Septiembre 1.995
[RFC1847] RFC1847: "Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted"
Jim Galvin
Sandy Murphy
Steve Crocker
Ned Freed
Octubre 1.995
[RFC1848] RFC1848: "MIME Object Security Services"
Steve Crocker
James M. Galvin
Sandra Murphy
Ned Freed
Octubre 1.995
[RFC1854] RFC1854: "SMTP Service Extension for Command
Pipelining"
Ned Freed
Octubre 1.995
[RFC1869] RFC1869: "SMTP Service Extensions"
John Klensin
Ned Freed
Marshall T. Rose
Einar A. Stefferud
Dave Crocker
Noviembre 1.995
[RFC1870] RFC1870: "SMTP Service Extension for Message Size
Declaration"
John Klensin
Ned Freed
Keith Moore
Noviembre 1.995
[RFC1872] RFC1872: "The MIME Multipart/Related Content-type"
Edward Levinson
Diciembre 1.995
[RFC1873] RFC1873: "Message/External-Body Content-ID Access
Type"
Edward Levinson
James Clark
Diciembre 1.995
[RFC1874] RFC1874: "SGML Media Types"
Edward Levinson
Diciembre 1.995
[RFC1891] RFC1891: "SMTP Service Extension for Delivery Status
Notifications"
Keith Moore
Enero 1.996
[RFC1892] RFC1892: "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages"
Gregory M. Vaudreuil
Enero 1.996
[RFC1893] RFC1893: "Enhanced Mail System Status Codes"
Gregory M. Vaudreuil
Enero 1.996
[RFC1894] RFC1894: "An Extensible Message Format for Delivery
Status Notifications"
Keith Moore
Gregory M. Vaudreuil
Enero 1.996
[RFC1895] RFC1895: "The Application/CALS-1840 Content-type"
Edward Levinson
Febrero 1.996
[RFC1896] RFC1896: "The text/enriched MIME Content-type"
Peter W. Resnick
Amanda Walker
[RFC1927] RFC1927: "Suggested Additional MIME Types for
Associating Documents"
Craig Milo Rogers
Abril 1.996
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
