Michael,
I have no argument with your summary.
I'd just like to clarify that I was never considering that IPP might be
changed in any way: my illustration (and it was no more than that) was the
idea that IPP might be used in some way to move messages between message
stores (a kind of spooling process?).
I think I'm hearing that the issue of s&f interaction is not an immediate
requirement.
#g
At 11:11 31/03/99 -0800, Michael Crawford wrote:
>Replying to your response to Graham...I'd like to propose the following:
>>1. I think timely delivery IS a key attribute...however, this doesn't
>relieve us from assuring the spec does not deal with devices that are valid
>in terms of addressing (for instance I have an IP address resolved from a
>DNS lookup) but are not currently up, connected, or operational). Graceful
>response to the three "unavailable" conditions indicated MUST be addressed
>in our deliberations. If its up, ok. If its not, gracefully exit.
>>2. The question is if IPP deals with unconnected devices...since one of the
>charter goals appears to NOT make changes to IPP (I personally think it
>ludicrous to prohibit changing a brand new spec, but am willing to back off
>on that). If IPP doesn't deal gracefully with unconnected but well known
>devices, then that is an issue for IPP AND anything we do here.
>>3. If at some time in the future we decide we need to address a fallback
>mode (store and forward or re-connect attempts at a later time), then we can
>discuss it then...for now, I am personally willing to leave the fallback
>issue for later (if at all) discussion. Just as long as we address the
>number 1 above.
------------
Graham Klyne
(GK at ACM.ORG)