Re: Federation protocols

Melvin Carvalho wrote:
>
>
>
> On 1 June 2013 16:50, Miles Fidelman <mfidelman@meetinghouse.net 
> <mailto:mfidelman@meetinghouse.net>> wrote:
>
>     Melvin Carvalho wrote:
>
>
>
>
>         On 1 June 2013 14:54, Miles Fidelman
>         <mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>
>         <mailto:mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>>> wrote:
>
>             Melvin Carvalho wrote:
>
>
>
>
>                 On 1 June 2013 03:49, Miles Fidelman
>                 <mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>
>                 <mailto:mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>>
>                 <mailto:mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>
>
>                 <mailto:mfidelman@meetinghouse.net
>         <mailto:mfidelman@meetinghouse.net>>>> wrote:
>
>                     Melvin Carvalho wrote:
>
>
>                         We could indeed use SMTP for messaging and it has
>                 advantages,
>                         but it would be nice to get the web up to be
>         able to do
>                         something as simple as sending messages
>         between two
>                 parties
>                         after more than 20 years.  We're not there
>         yet, and if
>                 we can
>                         even achieve that small step it's a victory!
>
>
>                     Umm, why?
>
>                     Messaging is messaging.  The "web" is HTTP and
>         hypertext -
>                     client-server computing.  Two different things.
>
>                     And, by the way, there've been server-based email
>         systems
>                 for at
>                     least 60 years.
>
>
>                 Try taking two users at random on the FSW on different
>                 networks.  Then try sending a message from user 1 to
>         user 2.
>                  In many cases there's no standard way to do it.
>
>
>             Ummm.... SMTP, SMS?
>
>
>         Sure what I mean is to translate that into the web.  ie that
>         you have a sender address and receiver address with a message
>         body.  Major communication systems, SMS, email, telphone,
>         postal service all can do this, but strangely the web (ie
>         http) cant yet.  HTTP POST lets you send to an address and a
>         message body, but does NOT easily allow you to see who the
>         sender is.
>
>
>     Might I point out that it really damages your credibility if you
>     don't actually understand what different protocols do, and the
>     whole concept of layering.
>
>
> Thanks for the feedback, I will try to be clearer, and am always happy 
> to improve my understanding.  Re credibility, I wasnt sure I had any! :)
>
>
>     HTTP POST does NOT allow you to send to an address - it allows you
>     to do a transaction between a client and a server (a specific
>     machine, or something that masquerades as a single machine).  Any
>     messaging going on is layered on top of (or below) HTTP - as in
>     posting an email message to a mail server via HTTP, instead of
>     SMTP -- when you use webmail, all you're doing is layering a GUI
>     on top of some messaging infrastructure.
>
>
> I see you point, but my understanding is that HTTP POST allows both 
> headers and a payload.  The payload could in theory be used to send a 
> message.  However, to add the address of the sending party is 
> problematic, meaning that the receiver doesnt always easily know who 
> the message was from.  There are a number of headers that could be 
> used or this such as:
>
> "From" : however this tends to be email only as it was inherited from 
> the email paradigm
>
> "User-Agent" : however this is used to identify the browser, rather 
> than, the user.  Webmasters may note that spiders such as google and 
> baidu actually stuff the http address of the spider into this field as 
> part of a csv, though this is not idea.
>
> To my knowledge, there's no top level header in the HTTP spec that 
> allows you to identify an HTTP user.  We could make one, but that 
> would be something new, that requires some text, and some consensus.
>

Umm... HTTP authentication and/or SSL client side certificates.

Again... layering, and using protocols for their intended and designed 
purpose.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

Received on Saturday, 1 June 2013 16:13:28 UTC