समस्या यह है कि HTML ईमेल के साथ संगत नहीं है। यही कारण है कि मैंने Mail Markup Language बनाया।
एचटीएमएल HTTP प्रोटोकॉल के साथ काम करने के लिए बनाया गया था क्योंकि उन दोनों तकनीकों का एक ही समय में उसी व्यक्ति द्वारा आविष्कार किया गया था। अंतर यह है कि HTTP एक सर्वर से एक क्लाइंट में एक ही सत्र हस्तांतरण एक तरीका है। एचटीएमएल दस्तावेज़ हमेशा सर्वर पर उत्पन्न होता है, जो कभी भी बदलता नहीं है, अनुरोधकर्ता क्लाइंट को भेजा जाता है, और एक बार ट्रांसफर क्लाइंट और सर्वर के बीच कनेक्शन को पूरा कर देता है।
ईमेल इस तरह से व्यवहार नहीं करता है। ईमेल में एक क्लाइंट में एक संचार उत्पन्न होता है, जिसे एक या अधिक ईमेल पर भेजा जाता है, और फिर एक दूरस्थ ग्राहक पर समाप्त होता है। हालांकि, सबसे बड़ा अंतर यह है कि दस्तावेज़ एक ट्रांसमिशन इंस्टेंस की अंतिमता के साथ मर नहीं जाता है, जैसा HTTP पर दस्तावेज़ हस्तांतरण के मामले में होता है। एसएमटीपी में भेजे गए एक दस्तावेज़ को कई अनिर्दिष्ट उपयोगकर्ताओं को उत्तर, अग्रेषित या कॉपी किया जा सकता है। ईमेल अंतर के लिए विचार करते समय यह एक अंतर गहरा होता है।
समस्या यह है कि एसएमटीपी और HTTP पहले दो पैराग्राफ में दिखाए गए अनुसार अलग हैं। यह मतभेद उस एसएमटीपी और HTTP में एकत्रित है, हेडर डेटा के निर्माण के लिए मूल रूप से अलग स्वरूपण विधियां हैं। एचटीएमएल में हेडर डेटा है जिसका उद्देश्य HTTP प्रसारण के शीर्षकों के साथ संगत होना है और एसएमटीपी प्रसारणों का अनुपालन नहीं करना है। एचटीएमएल हेडर भी ईमेल थ्रेड की जटिलता के लिए जिम्मेदार नहीं हैं।
समस्या का उदाहरण उदाहरण दिया गया है जब ईमेल सॉफ़्टवेयर उस सॉफ़्टवेयर की अनुरूप मांगों को पूरा करने के लिए आवश्यक स्वरूपण परिवर्तन जोड़ने के लिए HTML दस्तावेज़ को दूषित करता है और सीधे दस्तावेज़ में हेडर डेटा भी लिखता है। जब कोई HTML ईमेल ईमेल थ्रेड बन जाता है तो यह उदाहरण अत्यधिक स्पष्ट हो जाता है। चूंकि HTML हेडर डेटा में ईमेल थ्रेड की जटिलताओं के लिए कोई तरीका नहीं है, इसलिए दस्तावेज़ के हस्तांतरण से बचने वाली स्टाइलशीट से प्रासंगिक प्रस्तुति परिभाषाओं को आपूर्ति करने का कोई तरीका नहीं है। प्रत्येक बार एक HTML दस्तावेज़, या HTML स्वरूपण वाले दस्तावेज़ को एक ईमेल सॉफ़्टवेयर से दूसरे में भेजा जाता है, दस्तावेज़ दूषित हो जाता है और प्रत्येक ईमेल सॉफ़्टवेयर डिवाइस पूर्व भ्रष्टाचार को दूषित करता है। ईमेल प्रोसेसिंग सॉफ़्टवेयर या तो एक ईमेल क्लाइंट का संदर्भ ले सकता है, जो निश्चित रूप से किसी दस्तावेज़ या किसी ईमेल सर्वर को दूषित कर देगा, जो संभवतः एक ईमेल दस्तावेज़ को भ्रष्ट कर सकता है।
समस्या का समाधान एक मार्कअप भाषा सम्मेलन बनाना है जो सीधे ईमेल हेडर डेटा की आवश्यकताओं को पहचानता है। क्लाइंट प्रोसेसिंग के लिए एसएमटीपी प्रोटोकॉल और आरएफसी 5322 के लिए आरएफसी 5321 में उन आवश्यकताओं को परिभाषित किया गया है। ईमेल थ्रेड की जटिलताओं के लिए इस समाधान को सही तरीके से बढ़ाने का एकमात्र तरीका बहु-एजेंट डीओएम के लिए एक सम्मेलन प्रदान करना है।
तकनीकी त्रुटिपूर्णता और बहु-एजेंट डीओएम शब्द और एक आविष्कारित विशेषता की प्रकृति के बीच अंतर को संपादित करने से पहले यहां वर्णित पैराग्राफ हटा दिए गए हैं।
संपादित करें: एक बहु-एजेंट डोम कुछ पदानुक्रम लागू करता है, जो ईमेल थ्रेड का प्रतिनिधित्व करने के लिए आवश्यक नहीं हो सकता है।
स्रोत
2010-03-20 23:49:50
"(यानी एक ही सटीक स्रोत संदेश HTML या संक्रमण में पांव मार का कारण नहीं हो सकता है)" लेकिन जब वे कारण संक्रमण है जो मेल प्रदाता में आप आमतौर पर है कि समस्या मिल में पांव मार? हॉटमेल? जीमेल या कोई अन्य? या इससे कोई फर्क नहीं पड़ता कि रिसीवर मेल क्या है? –
मैंने सभी ईमेल प्रदाताओं के साथ समस्याएं देखी हैं। गंतव्य उपयोगकर्ता के प्रदाता के लिए विशिष्ट प्रतीत नहीं होता है। –
एन्कोडिंग क्या है? बेस 64 का प्रयास करें, भले ही अटैचमेंट न हो। जो चीजों को ठीक रखना चाहिए। – dusoft