Elektronikus ügynök megvalósítása SLP protokollal

Muhi Dániel Veszprémi Egyetem, Információs Rendszerek Tanszék dani@vekoll.saturnus.vein.hu

Dr Tarnay Katalin Veszprémi Egyetem, Információs Rendszerek Tanszék

katalin.tarnay@irt.vein.hu

Az elektronikus kereskedelem elterjedésének egyik komoly hátráltató tényezője az, hogy a lehetséges vevők nehezen találják meg az Interneten a megvásárolni kívánt termékeket. Ennek a problémának a megoldására az elektronikus ügynökök próbálnak segítséget nyújtani. Célom az volt, hogy létrehozzak egy hatékony elektronikus ügynököt. Ezt úgy valósítottam meg, hogy a terméket szolgáltatásnak tekintettem, melyet a vevő az SLP szolgáltatás-felfedező protokoll segítségével találhat meg. Az ügynök modelljének alkalmazásaként kifejlesztettem egy szoftvert, mellyel a felhasználó gyorsan információhoz jut egy adott termékről. Előadásomban szeretném bemutatni a modell alkalmazását és lehetséges továbbfejlesztését.

Kulcsszavak: e-kereskedelem, e-ügynök, SLP, szolgáltatás-felfedezés

Bevezető

A különböző információs és kommunikációs technológiák az egész világot megváltoztatják: a gazdasági folyamatok, a közigazgatási tevékenységek és a lakosság napi életének bizonyos részei egyre inkább az információs eszközök által nyújtott új lehetőségek segítségével valósulnak meg. Kialakul az információs társadalom, melyen belül az egyik leggyorsabban fejlődő terület az elektronikus kereskedelem.

Habár már megjelentek az elektronikus kereskedelmet támogató legfontosabb technológiák, még sokat kell fejleszteni rajtuk. Ezért ezen a területen rengeteg új dologgal találkozhatunk. A hagyományos technológiák általában valamilyen vállalati hálózathoz kötődnek, míg az újak rendszerint az Internettel állnak kapcsolatban, és gyakran magukban foglalják az előbbieket, például egy Interneten működő vállalati hálózat esetében. Az Internet jelentősége abban áll, hogy az elektronikus kereskedelmet átalakítja egyszerű adattovábbításból olyan mindennapi tevékenységgé, mely egy egyszerű és mindenütt jelenlévő hálózaton keresztül folyik.

Ez az átalakulás nem lesz zökkenőmentes. Mind az eladók, mind a vevők számos kihívással találják majd szembe magukat. Az eladóknak ki kell alakítaniuk egy vevői kört, és azt fenn kell tartani. A vevőknek pedig meg kell találniuk a számukra fontos termékeket az Interneten. Azonban a világhálón már most is olyan sok adat van, hogy sokszor még a legjobb keresőgépek is csak egy kis részét találják meg a keresett információnak.

Az egyik oldalon tehát ott van az eladó egy termékkatalógussal, a másikon pedig a vevő meghatározott igényekkel. Ahhoz, hogy a megfelelő vevő és eladó gyorsan egymásra találjon, szükség van egy harmadik szereplőre, az elektronikus ügynökre. Akárcsak a valódi életben, az ügynök szerepe itt is az, hogy kapcsolatot teremtsen a vevő és az eladó között olyan módon, hogy az mindkét fél hasznára váljék. Az elektronikus ügynök tevékenységi köre azonban ennél szélesebb: a kapcsolatteremtésen túl annak fenntartását is segítenie kell, de kétségtelen, hogy a kapcsolat létrehozásának nagyobb jelentősége van.

Ezért most megvizsgálom egy kapcsolatteremtésre szánt elektronikus ügynök modelljét, illetve lehetséges felhasználási területeit. A kapcsolatfelvétel azzal kezdődik, hogy a vevő elkezd böngészni az Interneten, a megfelelő termék után kutatva. A legnagyobb probléma ekkor az, hogy rengeteg oldalt át kell néznie, mire megtalálja a kívánt árut. Ezért a vizsgált elektronikus ügynök feladata az lesz, hogy segítse a vevőt ebben a munkában. Ezt úgy teszi, hogy a lehető legtöbb eladótól összegyűjti az eladni kívánt termékekre vonatkozó információt, majd ezt a vevő rendelkezésére bocsátja. A vevőnek így nem kell külön-külön minden eladó honlapját meglátogatnia, hanem az ügynökhöz fordulva egyetlen művelettel lekérdezheti az őt érdeklő termékek adatait.

Az elektronikus ügynök modellje az 1. ábrán látható:

4. ábra Elektronikus ügynök modellje

Napjainkban egyre többször lehet hallani a szolgáltatás-felfedezésről, amely egy újfajta hálózati technológia. Lényege az, hogy egy lokális hálózaton vagy az Interneten egy szolgáltatást a tulajdonságai, ne pedig a címe alapján találjunk meg. A szolgáltatás-felfedezés szolgáltatás-felfedező protokollok segítségével történik. Ezeket a protokollokat arra tervezték, hogy hálózati szolgáltatásokkal (pl. nyomtató, fax, adatbázisok) dolgozzanak.

Úgy gondolom, hogy ezek a protokollok elég rugalmasak ahhoz, hogy ne csak hálózati, hanem kereskedelmi szolgáltatásokat is fel tudjanak fedezni, azaz alkalmasak legyenek az ügynöki feladat ellátására. Erre a célra a legmegfelelőbb az SLP protokoll, mivel szolgáltatások széles skálájával tud dolgozni, ráadásul rugalmasan skálázható, olyannyira, hogy minden valószínűség szerint ki lehetne terjeszteni az egész Internetre. Ez pedig azt jelenti, hogy alkalmas egy globális kereskedelmi információs rendszer céljára is.

A következőkben be szeretném mutatni, hogyan lehet az SLP szolgáltatás-felfedező protokollt kereskedelmi szolgáltatások felfedezésére használni. Remélem, hogy ezzel új megvilágításba helyezem a szolgáltatás-felfedezést, mert tudomásom szerint még senki nem alkalmazott szolgáltatás-felfedező protokollt ilyen célra.

Szolgáltatás-felfedezés

Az Internet nemcsak az elektronikus kereskedelmet változtatja meg, átalakítja a World Wide Web-et is. Ma a webre úgy tekintünk, mint dokumentumok halmazára, és amikor megadunk egy URL-t, akkor egy dokumentumot kapunk válaszként. Az emberek azonban általában nem dokumentumokat keresnek, hanem szolgáltatásokat. Ezért nagyon valószínű, hogy a web nemsokára átalakul nyitott szolgáltatások globális piacává, azaz az eddigi dokumentum-orientált rendszer szolgáltatás-orientálttá válik.

Természetesen ez nem azt jelenti, hogy eltűnnek a webről a dokumentumok, hanem azt, hogy valamilyen technológia segítségével a felhasználók számára szolgáltatások halmazaként fog megjelenni ugyanaz a rendszer. Az URL ekkor nem egy dokumentumot fog meghatározni, hanem egy szolgáltatást és annak jellemzőit (attribútumait). Ha a felhasználó beírja ezt az URL-t a böngészőbe, az megkeresi számára a kívánt szolgáltatásokat valamilyen protokoll segítségével. Ez a technológia a szolgáltatás-felfedezés, a protokoll pedig a szolgáltatás-felfedező protokoll.

Nézzük meg egy példán, hogy mi a különbség a két modell között! Ha valaki egy Portugáliáról szóló elektronikus útikönyvet szeretne letölteni, akkor azzal kezdi, hogy egy internetes keresőgépbe beírja a megfelelő keresőszavakat, majd a találatként kapott oldalakat egyenként végignézi, megkeresi, hogy hol található maga a könyv az oldalon belül, letölti (feltéve, hogy ingyenesen letölthető), és elolvassa.

Tegyük fel, hogy ez a felhasználó szolgáltatás-felfedezés segítségével szeretné megtalálni a dokumentumot. Ehhez meg kell adnia a szolgáltatás típusát (ebook), valamint attribútumait (cím=Portugália, témakör=útikönyv). Ezután a felfedező protokoll megkeresi az attribútumoknak megfelelő szolgáltatások URL-jeit, és a felhasználó rendelkezésére bocsátja azokat, tehát keresőgépek használata nélkül azonnal pontos eredményhez jutunk.

Elosztott rendszerek

A jelenlegi hálózati architektúrák leginkább a kliens-szerver modellt alkalmazzák, melynek az a lényege, hogy van egy központi gép, a szerver, és a kliensek ennek a gépnek a szolgáltatásait használják. A kliensek egyszerűen elérik a kívánt szolgáltatást, hiszen csak a szerver hálózati címét kell tudniuk.

A jövő hálózatai azonban túlnyomórészt elosztott rendszerek lesznek. Ez azt jelenti, hogy egy hálózaton bármely gép nyújthat szolgáltatást, és bármely gép használhatja ezt a szolgáltatást, azaz bármely gép lehet kliens és szerver is, vagy akár mindkettő egyszerre. Ilyen körülmények között már jóval nehezebb megtalálni egy szolgáltatást, hiszen a hálózaton jelenlévő összes gépet le kellene kérdezni ahhoz, hogy az összes szolgáltatásról információhoz jussunk.

A szolgáltatás-felfedező protokollok ezt a problémát próbálják megoldani, és ezáltal biztosítani az elosztott rendszerek működését. Ma már számos szolgáltatás-felfedező protokoll létezik. A legelterjedtebbek a Jini, az SLP és az UPnP. Az SLP-ről azért érdemes hosszabban beszélni, mert ezt a protokollt az IETF dolgozta ki, mely független és demokratikus szervezet. Az összes többi protokollt valamilyen vállalat vagy érdekcsoport fejlesztette ki, ezért az SLP esetében biztosak lehetünk abban, hogy csak a legjobb ötletek kerültek be a protokollba. Ráadásul az SLP internetes szabványtervezet, így minden részletre kiterjedően dokumentálva van [1,2].

Az SLP

Az SLP architektúrának három fő eleme van:

• Service Agent (SA): Ez az elem egy adatbázist tart fenn a hozzá tartozó szolgáltatásokról. Az adatbázis elemei a szolgáltatás-leírások. A szolgáltatás-leírás tartalmazza egy adott szolgáltatás azonosítóját, típusát, valamint jellemzőit (attribútumait).

• User Agent (UA): Ha egy felhasználónak vagy szoftverkomponensnek szüksége van egy szolgáltatásra, akkor ehhez az elemhez fordul kérésével. Az UA feladata az, hogy az SA-któl megszerezze a kívánt szolgáltatásra vonatkozó összes információt, majd ezt a felhasználó rendelkezésére bocsássa, vagy egy előre megadott kritérium szerint automatikusan kiválasszon egy szolgáltatást.

• Directory Agent (DA): Szerepe az, hogy összegyűjtse az SA-któl a szolgáltatás-leírásokat. Ha ez megtörtént, akkor az UA-nak nem kell egyenként lekérdeznie az összes SA-t, hanem a DA-hoz fordulva azonnal megkapja a választ. Kisebb hálózatok esetén nem biztos, hogy jelen van, de mi ezentúl feltesszük, hogy legalább egy DA mindig aktív.

A fenti elemek közötti kapcsolatokat a 2. ábrán láthatjuk:

4. ábra Az SLP architektúrája

A szolgáltatás-leírás

A szolgáltatás-leírás a szolgáltatások legfontosabb jellemzőit tartalmazza: a szolgáltatás egyedi azonosítóját, típusát, illetve attribútumait.

A szolgáltatás azonosítójának neve service: URL. Ez egy speciális URL, melynek formája a következő:

„service:” szolgáltatástípus „:” SAP

ahol a SAP a szolgálatelérési pont (Service Access Point), mely megadja a szolgáltatás hálózati címét és elérési útját.

A szolgáltatástípus az SLP-ben lehet absztrakt vagy konkrét. Az absztrakt típus definiálja magát a szolgáltatástípust, a konkrét típus pedig a szolgáltatás eléréséhez szükséges protokollt is megadja. A következő service: URL egy absztrakt szolgáltatásra (device-drivers) mutat:

service:device-drivers://www.bean.org/drivers/

Az absztrakt típus csupán osztályozza a szolgáltatásokat, de ha egy bizonyos szolgáltatást akarunk elérni, akkor ezt egy konkrét típussal tehetjük meg. Egy konkrét típust ezért mindig egy absztraktból kell származtatnunk. A következő service: URL már egy olyan konkrét szolgáltatásra mutat, melyet fel is tudunk használni, azaz letölthetünk egy adott eszközmeghajtót:

service:device-drivers:ftp://ftp.driver.org/vol3/scsi.tgz

A konkretizálás úgy történt, hogy megadtuk a szolgáltatás eléréséhez szükséges protokollt (FTP) is. A konkrét szolgáltatást a device-drivers nevű absztrakt szolgáltatásból vezettük le.

Az attribútumok

Egy szolgáltatásnak sokféle tulajdonsága lehet. Az SLP-ben lehetőség van arra, hogy megadjuk a szolgáltatás bizonyos jellemzőit, így a felhasználó gyorsan kiválaszthatja a számára megfelelő szolgáltatást: csak meg kell adnia az UA-nak, hogy milyen attribútumokkal rendelkezzen a keresett szolgáltatás, az UA pedig a megadott kritériumok alapján kiszűri a megfelelőeket.

A példát tovább folytatva, tegyük fel, hogy a device-drivers szolgáltatásnak két attribútuma van: a type, mely megadja, hogy milyen eszközhöz való, és az OS, mely az operációs rendszert azonosítja. Ha egy linuxos SCSI eszközmeghajtóról van szó, akkor ezt a következő módon adhatjuk meg:

service:device-drivers:ftp://ftp.driver.org/vol3/scsi.tgz;driver=scsi;os=linux

A service: URL tehát gyakorlatilag minden információt tartalmazhat egy szolgáltatásról, és ezt az információt szabványos formában, URL-ként adja meg. Az SA ezt az URL-t jegyzi be a DA-ra, az UA pedig ezt kapja meg a DA-tól.

A template

A protokoll elemeinek tudniuk kell, hogy egy bizonyos szolgáltatásnak milyen attribútumai lehetnek. Ezt az információt az ún. template tartalmazza. A template egyszerű szöveges fájl, mely ember és gép számára egyaránt érthető.

A template első sora tartalmazza a szolgáltatás típusát, majd a lehetséges attribútumokat. A már említett konkrét szolgáltatástípushoz például a következő template tartozhatna:

template-type=service:device-drivers:ftp driver= string os= string

Ha egy absztrakt szolgáltatáshoz definiáltunk valamilyen attribútumot, akkor minden konkrét szolgáltatás, melyet ebből az absztrakt szolgáltatásból vezetünk le, örökölni fogja az absztrakt szolgáltatás attribútumait.

Az üzenetek

A protokollban definiált legfontosabb üzenetek a következők:

• Service Request: Az UA küldi ezt az üzenetet a DA-nak, ha információt szeretne kapni valamilyen szolgáltatásról. Az üzenet paramétereként meg kell adnia a kívánt szolgáltatás típusát, illetve egy szűrőfeltételt, mely alapján a DA visszaküldi a kritériumoknak megfelelő szolgáltatások adatait egy Service Reply üzenetben.

• Service Registration: Amikor egy új szolgáltatás elérhető lesz, akkor a hozzá tartozó SA küldi ezt az üzenetet a DA-nak. Hatására a DA bejegyzi a szolgáltatást adatbázisába, illetve törli onnan, ha egy Service Deregistration üzenetet kapott.

• DA Advertisement: A DA küldi az UA-nak és az SA-nak, hogy tudomást szerezzenek róla.

A felfedezés

A protokoll egyik legfontosabb tulajdonsága az, hogy az UA, illetve SA (kliensek) előzetes konfiguráció nélkül „felfedezik” a meghirdetett hálózati szolgáltatásokat. Hogyan teszik ezt? Tegyük fel, hogy hálózatunkban egy DA van. A felfedezés ekkor azt jelenti, hogy a klienseknek meg kell tudniuk a DA hálózati címét.

A megoldás a többesküldésben rejlik. Definiáltak egy Directory Agent Discovery Group nevű multicast csoportot, melynek IP-címe 224.0.1.35. Minden DA-nak csatlakoznia kell ehhez a csoporthoz. Ha egy kliens egy Service Request üzenetet küld erre a címre, és a szolgáltatás típusaként „directory-agent”-et ad meg, akkor a DA visszaküld a kliensnek egy DA Advertisement üzenetet, melyben szerepel a saját címe. A kliens feljegyzi ezt a címet, és ezután közvetlenül ide fordul kéréseivel.

Hogyan lesz az SLP-ből ügynök?

Ha most összehasonlítjuk az SLP és az elektronikus ügynök modelljét, láthatjuk a kettő közötti nagyfokú hasonlóságot.

4. ábra Az SLP és az elektronikus ügynök modelljének összehasonlítása

A két modell elemei egymásnak megfeleltethetőek, ezért az SLP alkalmas elektronikus ügynök megvalósítására. Az SLP-t azonban hálózati szolgáltatások felfedezésére tervezték, valahogyan képessé kell tenni kereskedelmi szolgáltatások hirdetésére.

Első lépésként definiálni kell magát a kereskedelmi szolgáltatást. Ez egy absztrakt szolgáltatás lesz, melyből majd levezethetjük a konkrét termékeket. Ennek a szolgáltatásnak a neve sale, és meg kell adni, hogy milyen attribútumai lehetnek. Mivel a sale típusból származtatunk majd minden konkrét típust, ezért azokat az attribútumokat kell tartalmaznia, melyek minden kereskedelmi termékre jellemzőek: a forgalmazót, a forgalmazó címét, az árat, illetve a pénznemet, melyben az árat megadták. Itt látható a sale típust leíró template:

Ezt a szolgáltatástípust még semmilyen gyakorlati célra nem lehet felhasználni, ezért bemutatunk egy konkrét típust, melyet a sale típusból származtatunk. A típus neve book, és könyvek leírására szolgál. Attribútumai a szerző vezeték- és keresztneve, a könyv címe, kiadója, a kiadási év, és az ISBN szám.

Természetesen a book típus tartalmazni fogja a sale típusban definiált attribútumokat is, hiszen a konkrét típus örökli az absztrakt típus attribútumait.

Ha egy könyvkereskedés meg szeretné hirdetni a könyveit, akkor annyit kell tennie, hogy létrehoz egy szöveges fájlt (regisztrációs fájl), melyben minden könyvhöz tartozik egy bejegyzés. A bejegyzés első sora a service: URL attribútumok nélkül, a többi sor pedig az attribútumokat adja meg:

service:sale:book://www.konyv.hu/eco/tokeletes author-last=Eco author-first=Umberto title=A tökéletes nyelv keresése publisher=Atlantisz Könyvkiadó publish-year=1998 isbn=963797886 vendor=Könyv Rt. location=Veszprém, Hóvirág út 6. price=2500 currency=Ft

Ezután el kell indítani az SA-t, mely kiolvassa a regisztrációs fájlból a szolgáltatás-leírásokat, majd a már említett többesküldési módszer segítségével megtalálja a DA-t, és bejegyzi a szolgáltatásokat. Ha egy vevő könyvet szeretne venni, akkor elindít egy UA-t, megadja a keresett könyv attribútumait, az UA pedig megkeresi a DA-t, és megkapja tőle a vevő igényeinek megfelelő könyvek service: URL-jeit, valamint attribútumait. A kapott adatokat rendezheti valamilyen szempont (pl. ár) szerint, így a vevő rögtön eldöntheti, hogy melyik terméket szeretné megvenni. Ezután a termék URL-jére kattintva megrendelheti a könyvet.

Alkalmazás

Az SLP-hez definiálták a standard API-t C és Java nyelvre [3], így a programozók adott függvények segítségével érhetik el a protokoll funkcióit. Ha valaki SLP-t szeretne használni, akkor legegyszerűbb, ha letölti az OpenSLP nevű szoftvert (http://www.openslp.org), mely nyílt forráskódú, és ingyenesen fel lehet használni bármilyen célra. Eredetileg Linux operációs rendszerre írták, bár Windows alatt is le lehet fordítani. Parancssorból működik, tehát az átlagfelhasználó számára elég barátságtalan.

Az eredeti OpenSLP még nem lenne alkalmas kereskedelmi szolgáltatások felfedezésére, mert az SA, illetve az UA túl egyszerű benne. Ezért először is írtam egy új SA-t Linux alatt, C nyelven. Azért esett a választásom a Linuxra, mert úgy gondoltam, hogy ez az operációs rendszer a legjobb eszköz hálózati protokollok fejlesztésére. Az SA feladata a szolgáltatások bejegyzése, melyek egy szöveges fájlban vannak megadva. Az SA beolvassa a fájlt, értelmezi, majd a service: URL-eket bejegyzi a DA-ra.

Az UA-t is újraírtam úgy, hogy a felhasználónak ne parancssorból kelljen megadnia az adatokat, hanem egyszerű kezelőfelületen tehesse ezt meg (4. ábra). A program írása közben jöttem rá, hogy nem is olyan egyszerű Linux alatt felhasználóbarát kezelőfelületet létrehozni. Ráadásul kiderült, hogy az OpenSLP-ben nem valósították meg azt, hogy a keresés kis- és nagybetűfüggetlen legyen, így még a DA-n is módosítanom kellett.

Az UA jelenlegi állapotában arra képes, hogy a DA-n bejegyzett könyvek közül kiválassza azokat, melyek a felhasználó számára érdekesek. Mint tudjuk, az UA két keresési paramétert küld a DA-nak: a szolgáltatás típusát, mely jelen esetben a book, és egy szűrőfeltételt. Ez a feltétel a kívánt attribútumértékek ÉS logikai kapcsolatából áll elő.

Egy könyvnek két olyan attribútuma van, melyek fontosak lehetnek a keresés során: a szerző és a cím. A book típusban valójában ez három attribútumot jelent, mivel a szerző vezeték- és keresztneve külön bejegyzésekben található.

A felhasználónak csupán annyit kell tennie, hogy begépeli a fenti három attribútumot az UA kezelőfelületén, majd az Enter leütése után az UA összeállítja ezekből a szűrőfeltételt, elküld a DA-nak egy Service Request kérést, benne a szűrőfeltétellel, a DA pedig ezek alapján egy Service Reply üzenetben visszaküldi a feltételeknek megfelelő service: URL-eket. Az UA értelmezi ezeket, és minden elemhez megjeleníti a legfontosabb attribútumokat, valamint az URL-t. A vevő ezután az URL alapján megrendelheti a terméket. Az UA a találatokat ár szerint rendezi. A 4. ábrán az UA-t láthatjuk futás közben:

4. ábra Az UA felülete

Az alkalmazás nehézségei

Természetesen semmi értelme nincs egy olyan ügynöknek, mely csupán egy lokális hálózaton belül működik. De egy városi hálózat (Metropolitan Area Network, MAN) már elég sok embert és szolgáltatást összefog ahhoz, hogy alkalmas legyen kereskedelmi célú szolgáltatás-felfedezésre. A legvégső cél természetesen az lenne, hogy a felfedezést kiterjesztjük az egész Internetre, így a vevők akkor is megtalálnák a keresett terméket, ha az a Föld túloldalán kapható.

Az SLP fejlesztői megígérték, hogy kiadnak egy olyan dokumentumot, melyben leírják, hogyan lehet kiterjeszteni az SLP-t az egész Internetre. Ez a dokumentum még nem jelent meg, de nyilvánvaló, hogy a cél eléréséhez egyetlen feltétel szükséges: az, hogy az Interneten bármely gép elérhető legyen többesküldéssel. Ettől azonban ma még távol vagyunk, mivel a routerek többsége ma még nem támogatja a többesküldést. De akkor hogyan lehetséges a felfedezés?

A kérdésre az egyik lehetséges válasz a DHCP. Ezzel a protokollal konfigurációs adatokat lehet különböző hosztoknak továbbítani TCP/IP hálózatokon. A DHCP-nek van egy opciója, mely arra szolgál, hogy a konfigurációs adatok a DA-k IP-címeit tartalmazzák [4]. Így lehetőség van arra, hogy a kliensek egy DHCP szervertől kapják meg a DA-k címét. Az IPv6-ban már alapkövetelmény a többesküldés, de egy jó darabig valószínűleg még DHCP-t kell alkalmazni a felfedezésre.

Irodalom

1. J. Veizades, E. Guttman, C. Perkins, S. Kaplan: Service Location Protocol, RFC2165 (ftp://ftp.isi.edu/in-notes/rfc2165.txt)

2. E. Guttman, C. Perkins, J. Veizades, M. Day: Service Location Protocol, Version 2, RFC2608 (ftp://ftp.isi.edu/in-notes/rfc2608.txt)

3. J. Kempf, E. Guttman: An API for Service Location, RFC2614 (ftp://ftp.isi.edu/in-notes/rfc2614.txt)

4. C. Perkins, E. Guttman: DHCP Options for Service Location Protocol, RFC2610 (ftp://ftp.isi.edu/in-notes/rfc2610.txt)