Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/Z5I4PBVQCHUI5H64QVFLXQM3BLTKPGUH/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "Z5I4PBVQCHUI5H64QVFLXQM3BLTKPGUH",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/R7Q7L6GL6UZ4CIL74HPC3LSIM3JTW33B/?format=api",
    "sender": {
        "address": "brickle (a) pobox.com",
        "mailman_id": "9bdc848cce7f42f494231f68bee93c59",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/9bdc848cce7f42f494231f68bee93c59/emails/?format=api"
    },
    "sender_name": "Frank Brickle",
    "subject": "[eagle] Re: Service class names",
    "date": "2006-10-10T03:37:33Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/QKQWZ4LGFTOBKEXBUSH6JHMYDILV32CW/?format=api",
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "One of the big advantages of XMPP (Jabber) as the underlying\nprotocol is a rich set of services that depend only on the\nterrestrial servers for their implementation. And it's all there\nalready, servers and clients both.\n\nIf somebody wanted to do it, an AX25 - XMPP gateway would be\npretty simple to construct, purely as an adjunct to a terrestrial\nserver implementation.\n\nSimilarly, if there were a need, it would be trivial to\nencapsulate APRS messages in XMPP. Not the other way around, however.\n\n73\nFrank\nAB2KT\n\nRobert McGwier wrote:\n> John B. Stephensen wrote:\n>> I hope that the U/V digital service is 8-bit transparent so that it can be \n>> used efficiently for non-text communication, like APRS and collecting \n>> weather data with the fewest number of bits. It's also not a \n>> store-and-forward system so it really isn't messaging - although that could \n>>   \n> \n> To keep the system stateless on the spacecraft since we do not want to \n> add a coprocessor,  increase the internal communications complexity \n> etc.  Frank proposes and I support him since I believe it is right that \n> we will use jabber servers on the ground to hold the data AND do \n> store/forward.  I do not want to build a messaging file system,. etc. on \n> the spacecraft.  Cooperation servers on the ground, using the net to \n> move data between them,  seems to be the right way to go.\n> \n> We particularly like the ejabber server.  It is implemented in Erlang/OTP.\n> \n> The conference went well.   I am taking a couple of days off from AMSAT \n> and spending them with Shann, N2HPE,  touring.  I will be home Wednesday.\n> \n> Bob\n> \n> \n> \n>> be added if message size was restricted. The number of data rates \n>> implemented in the ACP or SDX could be increased, so attaching names to each \n>> data rate may be a problem. How about calling class 1 advanced low-speed \n>> satellite communication (ALSC) and class 2 and 3 advanced high-speed \n>> satellite communication (AHSC)? There could then be a suffix for each data \n>> rate, such as AHSC-4800 and AHSC-256K.\n>>\n>> 73,\n>>\n>> John\n>> KD6OZH\n>>\n>>\n>>   \n>>   \n> \n> \n\n",
    "attachments": []
}