Groupe de travail sur les réseaux	L. Masinter
Requête pour Commentaires : 2324 fr	1er Avril 1998
Catégorie : Information
Traduction : Yves lescop

Protocole Hyper Texte de Contrôle de Cafetière (HTCPCP/1.0)
"Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)"

Statut de cette note

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

Copyright © "Internet society" (1998) – tous droits réservés.

1	Raisonnement et portée

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.

2	Protocole HTCPCP

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).

2.1	Méthodes ajoutées de HTCPCP

2.1.1	La méthode "BRASSAGE", et l'utilisation du "POST"

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).

2.1.2	la méthode "GET"

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.

2.1.3	Méthode "PROPFIND"

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].

2.1.4	Méthode "QUAND"

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".

2.2	Champs d'en-tête de cafetières

HTCPCP recommande plusieurs champs d'en-tête de HTTP et définit quelques nouveaux.

2.2.1	Champs d'en-tête recommandés

2.2.1.1	Le champ d'en-tête de réponse "sûr".

[SUR] 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.

2.2.2	Nouveaux champs d'en-tête

2.2.2.1	Le champ d'en-tête "Acceptation-Ajouts"

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" )

2.2.3	Champs d'En-tête omis

Aucune option n'a été donnée pour le café décaféiné. Quel est le but ?

2.3	Codes retour de HTCPCP

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.

2.3.1	406 Non acceptable

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.

2.3.2	418 je suis une théière

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.

3	Le schéma URI de "café"

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.

4	Le type de supports de "message/cafetière"

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"

5	Contraintes opérationnelles

Cette section présente certains des problèmes opérationnels avec le déploiement omniprésent de HTCPCP.

5.1	Considérations de Synchronisation

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.

5.2	Traversée du "Firewall"

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.

6	Considérations de gestion du système

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].

7	Considérations Sécuritaires

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.

8	Remerciements

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.

9	Références

[RFC2068] Fielding, R., Gettys, J., nabab, J., Frystyk, H., et T. Berners-Lie, "Protocole de transfert hypertexte -- HTTP/1.1", RFC 2068, Janvier 1997.

[RFC2186] Wessels, D., et K. Claffy, "protocole d'antémémoire d'Internet (ICP), version 2," RFC 2186, septembre 1997

[CPMIB] Slavitch, M., "définitions des objets contrôlés pour les dispositifs de chauffage de boisson câblés de type égouttement en utilisant SMIv2", RFC 2325, 1 avril 1998.

[HTSVMP] Q. Stafford-Fraser, "Hyper Text Sandwich Van Monitoring Protocol , Version 3.2". En préparation.

[RFC2295] Holtman, K., et A. Mutz, "contenu de négociation transparente dans HTTP", RFC 2295, mars 1998.

[SAFE] K. Holtman. "Le champ d'En-tête Réponse Sûr", Septembre 1997.

[CAM] "la machine à café de la salle de Trojan", D. Gordon et M. Johnson, laboratoire informatique de l'université de Cambridge, < http://www.cl.cam.ac.uk/coffee/coffee.html >

[CBIO] "la cafetière de la salle de Trojan, biographie (non technique)", Q. Stafford-Fraser, laboratoire informatique de l'université de Cambridge, <http://www.cl.cam.ac.uk/coffee/qsf/coffee.html>.

[RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2230, Novembre 1997. Voir également < http://www.internode.com.au/images/toaster2.jpg >

[NTP] Moulins, D., "Network Time Protocol (version 3)cahier des charges, mise en place et analyse", RFC 1305, mars 1992.

[URLI18N] Masinter, L., "utilisation de UTF8 pour des caractères non-ASCII dans des URIs étendus" Travail en cours.

[PLUMB] B. Metcalfe, "plombier d'Internet de l'année : Jim Gettys ", Infoworld, 2 février 1998.

[COKE] D. Nichols, "histoire de machine de coka", C. Everhart, "utilisations intéressantes du réseau", < http://www- cse.ucsd.edu/users/bsy/coke.history.txt >.

10	Adresse de l'auteur

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

EMail: masinter@parc.xerox.com

11	Copyright intégral 

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 être modifié de quelque façon que ce soit, comme par exemple en retirant les observations de copyright ou les références à la Internet Society ou aux autres organismes de l'Internet, excepté comme l'exige le but du développement des standards Internet où dans un tel cas les procédures pour les copyrights définis dans le processus des Standards Internet doivent être suivies, ou alors comme l'exige une traduction dans une langue autre que l'anglais.

Les autorisations limitées accordées ci-dessus sont éternelles et ne pourront être révoquées par la Internet Society, ses successeurs ou ses repreneurs.

Ce document et les informations contenues ici sont fournis de façon " TELS QUELS " et les traducteurs, la Internet Society et la Internet Engineering Task Force déclinent toute garantie, explicites ou implicites, y compris mais pas seulement toute garantie que l'utilisation des informations de ce document ne violera pas des réglementations ou des garanties implicites commerciales ou physiques pour une application particulière.