Hello Jacob -- We mostly agree, but...
Lets not confuse the implementors checklist value with the timing
problem of vendors pre-announcing product features.
I completely endorse your plans to create the checklist, which will
both identify what we are going to be looking for from
interoperational testing on the path to Draft Standard, and will help
vendors decide what they want to include in their developments.
But, I don't think we should insist that they prematurely disclose
what they are going to implement. We don't need that information
until after they have competed implementation and proven it to
interwork. So, lets not put a lot of effort into such premature
reporting and collecting of such information.
Of course, we will not object to early announcements, but such
information does not count as proof of interworking products.
So, please continue development and exposssure of the checklist;-)...
It will be very helpful to have...
From Jacob's message Thu, 6 Nov 1997 05:53:04 +0100:
}At 13.22 -0800 97-11-05, Einar Stefferud wrote:
}> Speaking as MHTML Chair;-)...
}> It seems to me that our need for implementation reporting has a
}> deadline just before we need to decide about advancing from Proposed
}> to Draft Standard Status, but not sooner.
}> What we need then is to determine which pats of our standard have two
}> (or hopefully more) independent implementations that actually do
}> interoperate and interwork.
}> We do not need to know about developer's intentions before they
}> implement or before they annouce their products. So, I do not see any
}> reason to invade their privacy by asking for advanced information
}> about product plans.
}But since we can expect that future users of e-mail will be using
}many different products for e-mail, it is also very important that
}different developers of e-mail products develop compatible products,
}so that a user of product A can easily send mail to a user of
}product B and the reverse. This is made easier with more detailed
}forms of what each developer has done and plans to do. For example,
}it is not very valuable if A sends messages in multipart/alternative
}format, if B cannot receive them in a good manner. Or it is not very
}valuable if A sends messages containing URLs which must be resolved
}via http look up from the web, if B cannot handle such messages.
}The better we make e-mail work, the larger will the market be for
}use of e-mail. Hiding information from other developers might in
}the short run increase the market share of one company, but in the
}long run I believe all benefit by making e-mail work better so that
}the total market size increases.
}I also think my form can be used as a checklist by implementors
}to check which facilities they might consider to include in their
}Shall I make a shorter and simpler form? I can do it if you
}want. Or I could mark certain questions in the form as of more
}Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
}for more info see URL: http://www.dsv.su.se/~jpalme