What I was trying to do was raise general issues of dealing with
intermittently connected receivers so that a rational decision could be
made about whether they should be supported.
You raise more of the same, in the context of using IPP in a s&f context.
I really don't want to get into protocol detail at this time -- but the
points you raise certainly may need to be addressed if we were to try and
support a s&f mode using IPP.
#g
At 15:24 29/03/99 -0700, you wrote:
>
>>That may be so. But I wasn't thinking of that when I wrote that.
>>(Actually, I was thinking of possibly using IPP as a transfer mechanism
>>to/from a message store. But, my purpose here is not to discuss
>>solutions, but requirements, so that's equally irrelevant.)
>
>If we accept that some form of store and forward intermediary is possible
>(I'm not entirely convinced it's within the scope that we've been
>considering, but I'll go with the consensus) without necessarily discussing
>how the solution would work, it does bring up the issue of authentication
>between sender and recipient (the analog of the CSID string, time and date)
>and who gets notifications and when, so it's a good point to bring up.
>
>I think IPP could handle being the protocol for this sort of dial-up
>connection, but it wouldn't be an efficient way to do it. IPP is initiated
>by the client end rather than requested by the server, so any document
>store would have to act as an IPP client to transfer the stored document to
>its ultimate destination. However, the only mechanism I'm aware of to
>handle this store-and-forward functionality is repeatedly polling the
>server to see if it's up (that could be as simple as ICMP echoes, but it's
>still ugly).
>
>Then again, an ISP could implement a QualDocs repository which would be the
>document store you describe, with the dial up server using some other
>protocol (maybe SMTP) to get the job. I guess that's the same as the SMTP
>gateway I mentioned in an earlier post on the subject.
>Cheers,
>Nick Webb
>
>
>
------------
Graham Klyne
(GK@ACM.ORG)