| Groupe de Travail sur les Réseaux Requête pour Commentaires : 2324 - FR Catégorie : Information Traduction : Yves LESCOP (lycée la croix-rouge - Brest) |
Cette note fournit des informations pour la communauté d'Internet. Elle n'indique en aucune façon un standard d'Internet. La distribution de cette note est illimitée.
Copyright © "Internet society" (1998) - tous droits réservés.
Il y a du café partout dans le monde. De plus en plus, dans un monde dans lequel le calcul est omniprésent, les informaticiens veulent faire du café. Le brassage du café est un art, mais l'intelligence répartie du monde relié par le Web dépasse l'art. Ainsi, il y a une condition forte, foncée, riche pour un protocole conçu expressément pour la préparation du café. Le café est préparé à l'aide de cafetières. Les cafetières en réseau exigent un protocole de commande si elles doivent être contrôlées.
De plus en plus, la maison et les appareils du consommateur sont reliés à l'Internet. Les expériences avancées de gestion de réseau ont démontré le mode de surveillance des dispositifs vendus reliés à l'Internet [COKE]. Une des première machine actionnée à distance à être reliée à l'Internet, le grille-pain Internet, (contrôlé par l'intermédiaire de SNMP) était démarrée en 1990 [RFC2235].
La demande de connectivité universelle d'appareils provoque la consommation de l'espace d'adresses IPv4. Les consommateurs veulent télécommander des dispositifs tels que des cafetières de sorte qu'ils puissent se réveiller avec un café fraîchement préparé, ou que le café soit prêt à un temps précis après l'accomplissement des préparations du dîner.
Ce document indique un protocole hyper texte de contrôle de cafetière (HTCPCP), qui permet les requêtes et les réponses complètes nécessaires pour contrôler tous les dispositifs capables de faire les boissons chaudes cafeinées populaires.
HTTP 1.1 ([RFC2068]) permet le transfert aux clients des objets du Web à partir des serveurs d'origine. Le Web est mondial. HTCPCP est basé sur le HTTP. Ceci parce que le HTTP est partout. Il ne pourrait pas être si dominant sans être bon. Par conséquent, HTTP est bon. Si vous voulez un bon café, HTCPCP doit être bon. Pour rendre HTCPCP bon, il est bon de baser HTCPCP sur HTTP.
Les futures versions de ce protocole peuvent inclure des extensions pour des machines espresso et des dispositifs semblables.
Le protocole HTCPCP est établi sur le HTTP, avec l'ajout de quelques nouvelles méthodes, champs d'en-tête et codes retour. Tous les serveurs HTCPCP devraient être mentionnés avec le schéma URI "café:" (section 4).
Les commandes pour contrôler une cafetière sont envoyées du client au serveur de café en utilisant la méthode "BRASSAGE" ou "POST", et d'un corps de message avec le Type-Contenu réglé à "application/commande-cafetière".
Un serveur de cafetière DOIT accepter d'une manière équivalente les deux méthodes "BRASSAGE" et "POST". Cependant, l'utilisation de "POST" pour produire des actions est désapprouvée.
Les cafetières chauffent l'eau en utilisant des mécanismes électroniques, alors il n'y a aucun feu. Ainsi, aucun pare-feu ("firewall") n'est nécessaire, et la politique de commande d'un pare-feu est non pertinente. Toutefois, "POST" peut être une marque de café déposée, et ainsi la méthode "BRASSAGE" a été ajoutée. La méthode "BRASSAGE" peut être utilisée avec d'autres protocoles basés sur HTTP (par exemple, le protocole de commande de brasserie hyper texte).
Dans HTTP, la méthode "GET" est employée pour signifier que "recherchez quelque information (sous forme d'entité) identifiée par la demande URI." Si la demande-URI se rapporte à un processus producteur de donnée, ce sont les données produites qui seront retournées comme entité dans la réponse et non le texte source du processus, à moins que ce texte s'avère justement être la sortie du processus.
Dans HTCPCP, les ressources liées à une cafetière sont physiques, et non informationnelles. Les "données" de la plupart des URIs café ne contiennent aucune caféine.
Si la donnée est une tasse de café, la métadonnée au sujet de la ressource brassée est découverte en utilisant la méthode "PROPFIND" [WEBDAV].
Quand du café est versé, et que du lait est offert, il est nécessaire pour le détenteur du récipient de lait de dire "quand" au moment où suffisamment de lait a été introduit dans le café. À cette fin, la méthode "QUAND" a-t-elle été ajoutée à HTCPCP. Assez ? Dites "QUAND".
HTCPCP recommande plusieurs champs d'en-tête de HTTP et définit quelques nouveaux.
[SAFE] définit un champ d'en-tête de réponse de HTTP, "sûr", qui peut être utilisé pour indiquer que la répétition d'une demande HTTP est sûre. L'inclusion d'un champ en-tête "sûr : Oui" permet à un client de répéter une demande précédente si le résultat de la demande peut être répété.
La sûreté réelle des dispositifs pour préparer le café change considérablement, et peut dépendre, en fait, de conditions dans le client plutôt que juste dans le serveur. Ainsi, ce protocole inclut une extension à l'en-tête de réponse "sûr" :
Sûr = "Sûr" ":" nature-sûr
nature-sûr = "oui" | "non" | sûr-conditionnel
sûr-conditionnel = "si-" condition-sûr
condition-sûr = "éveil-utilisateur" | marque
L'indication permettra à des agents utilisateur de manipuler les relances de quelques demandes sûres, en particulier demandes sûres "POST", d'une manière plus conviviale.
Dans HTTP, le champ "Acceptation" d'un en-tête de demande est utilisé pour indiquer les types de supports qui sont acceptables pour la réponse. Cependant, en HTCPCP, la réponse peut avoir comme conséquence des actions supplémentaires de la part de la cafetière automatisée. Pour cette raison, HTCPCP ajoute un nouveau champ d'en-tête, "Acceptation-Ajouts" :
Acceptation-Ajouts = "Acceptation-Ajouts" ":"
#( ajout-intervalle [ accepte-params ] )
ajout-type = ( "*"
| type-lait
| type-sirop
| type-édulcorant
| type-épice
| type-alcool
) *( ";" paramètre )
type-lait = ( "Crème" | "moitié-moitié" | "lait-entier"
| "Demi-Écrémé" | "Écrémé" | "Sans-lait" )
type-sirop = ( "Vanille" | "Amande" | "Framboise"
| "Chocolat" )
type-alcool = ( "Whisky" | "Rhum" | "Kahlua" | "Aquavit" )
Aucune option n'a été donnée pour le café décaféiné. Quel est le but ?
Des codes de retour normaux HTTP sont employés pour indiquer les difficultés du serveur HTCPCP. Cette section identifie des interprétations spéciales et de nouveaux codes retour.
Ce code retour est normalement interprété comme "la ressource identifiée par la demande est seulement capable de produire des entités de réponse qui ont des contenus de caractéristiques non acceptables selon les en-têtes d'acceptation introduits dans la demande". Dans HTCPCP, ce code de réponse PEUT être retourné si l'opérateur de la cafetière ne peut pas se conformer à la demande d' "Acceptation-Ajout". À moins que la demande ait été une demande PRINCIPALE, la réponse DEVRAIT inclure une entité contenant une liste d'ajouts au café disponibles.
Dans la pratique, la plupart des cafetières automatisées ne peuvent pas actuellement fournir des ajouts.
N'importe quelle tentative de préparer du café avec une théière devrait avoir comme conséquence le code d'erreur "418 que je suis une théière". Le corps résultant d'entité PEUT être court et fort.
Puisque le café est international, il y a des schémas URI internationaux du café. Tous les schémas URL de café sont écrits avec un codage URL d'un codage des caractères UTF-8 qui orthographie le mot "café" dans n'importe lequel des 29 langages, suivant les conventions pour l'internationalisation dans les URIs [URLI18N].
café-URL = café-schéma ":" [ "//" host ]
["/" indicateur-cafetière ] ["?" liste-ajouts ]
café-schéma = ( "koffie" ; Afrikaans, Néerlandais
| "q%C3%A6hv%C3%A6" ; Azerbaïdjanais
| "%D9%82%D9%87%D9%88%D8%A9" ; Arabe
| "akeita" ; Basque
| "koffee" ; Bengali
| "kahva" ; Bosnien
| "kafe" ; Bulgare, Tchèque
| "caf%C3%E8" ; Catalan, Français, Galicien
| "%E5%92%96%E5%95%A1" ; Chinois
| "kava" ; Croate
| "k%C3%A1va ; Tchèque
| "kaffe" ; Danois, norvégien, Suédois
| "coffee" ; Anglais
| "kafo" ; Espéranto
| "kohv" ; Estonien
| "kahvi" ; Finlandais
| "%4Baffee" ; Allemand
| "%CE%BA%CE%B1%CF%86%CE%AD" ; Grec
| "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
| "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japonais
| "%EC%BB%A4%ED%94%BC" ; Coréen
| "%D0%BA%D0%BE%D1%84%D0%B5" ; Russe
| "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thaï
)
indicateur-cafetière = "pot-" entier ; pour des machines avec liste
d'ajout de pots multiple = # (ajout)
Toutes les formes alternatives de "café-schéma" sont équivalentes. Cependant, l'utilisation de "café-schéma" dans divers langages PEUT être interprétée comme une indication du genre de café produit par la cafetière. Notez que tandis que les noms de schéma d'URL sont indépendants de la casse, la capitalisation est importante pour l'Allemand et le "K" initial doit être encodé ainsi.
Le corps d'entité d'une demande "POST" ou "BRASSAGE" DOIT être du Type Contenu "message/cafetière". Puisque la majeure partie de l'information pour contrôler la cafetière est donnée par les en-têtes supplémentaires, la teneur de "message/cafetière" contient seulement un café-message-corps :
café-message-corps = "départ" | "arrêt"
Cette section présente certains des problèmes opérationnels avec le déploiement omniprésent de HTCPCP.
Une qualité de service robuste est exigée entre l'utilisateur de la cafetière et le service de cafetière. Les cafetières DEVRAIENT employer le "Network Time Protocol" [NTP] pour synchroniser leurs horloges à une norme de temps globalement précise.
Telerobotics a été une technologie chère. Cependant, avec l'arrivée de la cafetière de Cambridge [CAM], l'utilisation du Web (plutôt que du SNMP) pour le système de surveillance à distance et la gestion a été éprouvée. Des tâches supplémentaires d'entretien de cafetière pourraient être accomplies par la robotique à distance.
Les données du Web sont normalement statiques. Par conséquent pour réduire la transmission de données et gagner du temps, les programmes du navigateur enregistrent chaque page Web recherchée par un utilisateur sur l'ordinateur de l'utilisateur. Ainsi, si l'utilisateur veut retourner à cette page, elle est maintenant enregistrée localement et n'a pas besoin d'être demandée à nouveau au serveur. Une image utilisée pour la commande de robot ou pour surveiller une scène changeante est dynamique. Une version rafraîchie doit être recherchée sur le serveur chaque fois qu'elle est consultée.
Dans la plupart des organisations le trafic de HTTP traverse des pare-feux assez facilement. Les cafetières modernes n'utilisent pas le feu. Cependant, un "Firewall" est utile pour la protection de n'importe quelle source contre n'importe quelle sorte de chaleur, et pas simplement le feu. Chaque réseau d'ordinateur personnel DEVRAIT être protégé par un pare-feu contre des sources de chaleur. Cependant, la télécommande des cafetières est importante de l'extérieur de la maison. Ainsi, il est important que HTCPCP traverse facilement les pare-feux.
En basant HTCPCP sur le HTTP et en utilisant le port 80, il obtiendra toutes les vertus du HTTP pour la traversée d'un pare-feu. Naturellement, les pare-feux de la maison exigeront une reconfiguration ou des nouvelles versions afin de faciliter les méthodes spécifiques HTCPCP, des en-têtes et des bas de page, mais de telles mises à niveau seront facilement adaptées. La plupart des administrateurs système de réseau personnel boivent du café, et sont disposés à adapter le besoin d'un tunnel HTCPCP.
La surveillance de la cafetière en utilisant des protocoles HTTP a été une des premières applications du Web. Dans le premier exemplaire, la surveillance de la cafetière était une première utilisation (appropriée) des réseaux ATM [CAM].
La technique traditionnelle [CAM] devait relier un générateur de trame à un camescope, et alimenter un serveur web avec les images. C'était une application appropriée des réseaux ATM. Dans cette installation de cafetière, la salle de "Trojan" des laboratoires de l'université de Cambridge a été employée pour donner une interface Web pour surveiller une cafetière commune. Impliqués que nous étions dans la recherche relative et, étant pauvres, des académiciens appauvris, nous avons seulement disposé d'une cafetière à filtre entre nous, qui a vécu dans le couloir juste en dehors de la salle de "Trojan". Cependant, étant des académiciens fortement dévoués et travailleurs, nous avons obtenu beaucoup de café, et quand un pot frais a été filtré, il n'a pas souvent duré longtemps.
Ce service a été créé comme première application pour utiliser un nouveau mécanisme de RPC conçu dans le laboratoire d'ordinateur de Cambridge - MSRPC2. Il s'exécute au-dessus de MSNL (Multi-Service Network Layer : couche réseau Multi-Service) - un protocole de couche réseau conçu pour des réseaux ATM.
Des cafetières sur l'Internet peuvent être contrôlées en utilisant le MIB de cafetière [CPMIB].
N'importe qui, qui se met entre moi et mon café du matin devrait être peu sûr.
L'accès non modéré d'utilisateurs d'Internet aux cafetières non protégées pourrait mener à plusieurs attaques du genre de "déni de service de café". L'utilisation incorrecte des dispositifs de filtration pourrait admettre du marc de Trojan. La filtration n'est pas une bonne méthode de protection des virus.
Mettre du marc de café dans la tuyauterie d'Internet peut avoir comme conséquence une obstruction de la tuyauterie, ce qui nécessiterait les services d'un plombier d'Internet [PLUMB], qui pourrait, en retour, exiger un aide plombier d'Internet.
L'authentification de l'accès sera discutée dans une note séparée.
Beaucoup de mercis aux nombreux contribuants à cette norme, y compris Roy Fielding, Mark Day, Keith Moore, Carl Uno-Manros, Michael Slavitch, et Martin Duerst. L'inspiration du poney caracolant, de la machine à coka du CMU, de la cafetière de Cambridge, du grille-pain d'Internet, et d'autres dispositifs contrôlés à distance par ordinateur ont permis cette création valable.
[SAFE] K. Holtman. "Le champ d'En-tête Réponse Sûr", Septembre 1997.
[PLUMB] B. Metcalfe, "plombier d'Internet de l'année : Jim Gettys ", Infoworld, 2 février 1998.
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
EMail: masinter@parc.xerox.com
Copyright © The Internet Society (1998). Tous Droits Réservés.
Le document anglais original et les traductions de celui-ci peuvent être copiés et fournis à d'autres, et les travaux dérivés qui le commente ou l'explique ou facilite son implémentation peuvent être préparés, copiés, publiés ou distribués, en totalité ou en partie, sans aucunes restrictions tant que les observations ci-dessus sur le copyright et ce paragraphe sont inclus dans tous ces types de copies ou de travaux dérivés. Cependant, le document anglais original lui-même ne peut &eci