BMUG Revelations

home *** CD-ROM | disk | FTP | other *** search

/ BMUG Revelations / BMUG Revelations.toast / Telecom / Compression Programs / MacBin / MacBinary II Conference < prev next >

Wrap

Text File | 1989-03-27 | 60.6 KB | 1,195 lines | [TEXT/SNTE]

(Neil/Sysop) Basically, when a couple years ago we called the first... MacBinary CO telecom was much different than it is today... At that time all we wanted was a way to upload and download to the MAUG area. The MacBinary standard became a real standard when first BBS systems and then other nets picked up on it. In recognition of that I've asked Pete Olson from Delphi's ICONtact Roundtable to... help me chair this meeting and I have also asked people from other... nets to be here although I don't see 'em in /STA yet! Basically, I think what we need to address is how to revamp what we... now have so as to take advantage of the new goodies in the Finder and.. to do it in a way that will NOT obsolete files already uploaded in the... existing format. Let me just throw it over to Peabo from ICONtact and... see if he'd like to add anything... Peabo? ga PEABO:Peter Olson> ok ... we have a number of people here tonight ... and, barring technical difficulties with the link ... I hope we'll have a very productive CO that's all I have for now, but ... I'd like the ICONtact participants to press CR so everyone will know who's here MACINTOUCH:Ric Ford> CHESLEY:Harry Chesley> NWOLF:neil wolf> AESOP:Laird Heal> PEABO:Peter Olson> back to you, Neil (Neil/Sysop) Well, I think the first thing is to simply throw the floor open... to those who would like to make some opening remarks... (Donald/Sysop) Based on what people have uploaded here,... it looks as though we should probably look at setting... up two MacBinary protocols. One is a MacBinary 1.5, which... is virtually identical to MacBinary 1, except it makes... provision for the new Finder †system info. Additionally,... we want to consider a MacBinary II, that adds additional... capability to MacBinary, such as some sort of automatic... packing and/or compression (though the two people... who uploaded proposals both said that they thought.... compression was a bad idea). If we're going to... look at this sort of thing, though, I think that... compressions is vital. People are going to want... compression, I think that the biggest mistake that... Maug made was being slow in accepting a compression... protocol, but one thing we learned from it is that... PEOPLE WANT COMPRESSION. If all we offer is non-compression,... I think it will be ignored and people will... continue to use Packit II. Also, if we're going... to implement a packing, I think some sort of... method of specifying folders/directories is... also needed. I know that Yves disagrees, I'll... let him present his side rather than try to precis it here. (Yves) Two things:... First: I just checked and saw that only 4 people have my draft 2... of my proposal. Since it is only 5K long (1 min at 1200 baud)... maybe it would be a good idea for those who don't have it to get it... now. 2)... I'd like to extend on compression but maybe I should let the... others talk first. CHESLEY:Harry Chesley> OK... I just want to make the obvious point that it's redundant to extend packing and compression (damn this link, ptr)... to extend MacBinary to cover and compression when it's already been done with the PackIt format. You can leave the MacBinary header on a PackIt file for backward-compatibility, or remove it (it's possible to distinguish MacBinary from PackIt for space. In either event, the format is already well defined and there's a big investment present in uploaded files. Also, PackIt files do include all 16 Finder flag bits, and there will be a new version out soon that decodes them (V1.3). The only thing missing is folder info, and I know exactly how I would like to add that. (Gustavo A. Fernande) I already notice that someone from Apple is here. I just wanted to make sure that they were aware of this CO. I don't want a tower of babble of protocols, and I for one, disagree that there should be more than one new standard. That's all MACINTOUCH:Ric Ford> Leaving aside the compatibility questions, I see two main problems at present. One is support for 7-bit systems. Let's make it optional whether stuff is saved in 7-bit or 8-bit The other is bundling compression/packing in with the transfer protocol. I don't think it should be separate. (Neil/Sysop) If I can just interject as moderator... I agree strongly with Yves and Harry in that I think the... separate PackIt protocol has been proven to be workable and.... quite understandable -- far more than ARC in the IBM world... for example. Just a thought. MACINTOUCH:Ric Ford> That's not a very good recommendation! (Scott Watson) First, I'm a bit confused about exactly... what it is we're discussing here and I'd... like to propose that we all adopt the... same nomenclature for these discussions... First, "protocol" and "MacBinary" are... independent and do not affect each other. The Protocol (XMODEM, Kermit, et. al - or... even no protocol at all with error correcting... modems (or a lot of faith) has nothing... to do with the MacBinary header. "MacBinary Format"... is not a luxury (like multiple file sends or compression... ) it is an essential thing we need to insure that... a file arrives in the same condition that it left. I do recognize that we need to add the new Finder bits... but I wonder if we aren't putting the cart before the horse... since Apple has not yet released it's "Universal Finder", and... without some unapproved hacking, it's still not clear... just which Finder our client is using at a given moment. MacBinary itself does not limit the... protocol to an 8-bit protocol. Kermit, for instance, can not only use MacBinary in 7-bit, but it can... also do rudimentary compression and multiple file... sends. So, my question begs, are we really here to... "fix" the MacBinary header, or are we here to discuss... the relative virtues of different file transfer protocols. GA. NWOLF:neil wolf> Good point, Scott... It's obvious that even if packing/compression... were incorporated into MacBinary... there would still be room... for MORE packing and compression. ... So I think the issue here is more to determine changes... to the MacBinary Header... and leave file protocols for another CO. (Gustavo A. Fernande) several issues have been brought up. 1) macbinary vs protocols. perhaps there is some confusion here... since MacBinary can be considered both a protocol... (as implemented by many terminal programs) and a file format as implemented by BinHex 5. Let us note that in whatever way it is implemented, the purpose of MacBinary and is successor are still to provide a way to transfer a Macintosh file to a non-mac host in a way in which it can be retreived. 2) 7 bit vs 8 bit. Is this really an issue? Are there a lot of people out there who just cannot download Mac bi programs because they only have a 7 bit line? I think that 7 bit filter detection is adequate here... 3) MacBinary vs Packit. If Packit II is everything that it claims to be, why not use IT as the MacBinary replacement and avoid creating a new protocol. (Neil/Sysop) Well, I think we are pretty well established that... MacBinary is a format and that we must use the XMODEM or... Kermit or other 8-bit protocols we have to use that format with. MACINTOUCH:Ric Ford> Scott's points are well taken. But, last I knew, PackIt III wasn't public domain like MacBinary. And the problem is one of confusion of multiple elements that new telecom users have to deal with. Some shareware, some PD. Some on one network, some on another. Usenet/Arpanet people are using Binhex to deal with 7-bit systems. I'd really like to see a more solid *standard* for the whole schmeer. PEABO:Peter Olson> re: gus ... I think that the best thing to do is put PackIt inside ... a MacBinary envelope, because that way you still have ... a choice of downloading it in packed form, and you still ... have compatibility with files already uploaded. (Yves) Well, at the risk of being redundant (BTW, well said Scott)... I'd like to define 3 things: Layers, protocols and formats. First of all, "MacBinary" is a format and is in no way linked... to a protocol. A protocol or format can be divided in several... layers which each have their own tasks. For example: A file can be first encoded in MacBinary then compressed... then packed along with other files and finally sent over... a network using a multi-layer protocol. Or, the protocols can take care of the compression/ packing: Example: An error free link can be established using X.25, X.PC or MNP. The multiple file transfer can be done using FAST from Hayes. Each file would be MacBinary Encoded. There are many possiblities, but one thing is clear: It is in no way the job of the MacBinary format to handle... these things. Just to get one file across. (Donald/Sysop) Yves, it's all very well to talk about theoretical... protocols and so forth, but at least my personal interest is... in what's going on now. Right now, we've got a lot of... people calling in with 1200 baud modems, who've just... got their Mac, and they want to download some software... from the network. What can we do to make their life... easier? If we leave out the messages from people trying... to download MacBinary files using MacTerminal 1.1,... I'd guess 90% of the problems people report with downloading... are that they're having trouble with unpacking files (they... don't realize they need to do it). I like Peter's... and Bill Bond's point that we don't actually... have to build a compression/packing routine... into the format per se, merely recommend a standard... packed format, which if the terminal program is... not equipped to deal with would put a "packed" file on... the disk for later unpacking, but if the program is "smart"... about this, would unpack and uncompress on the fly. I'd... have no problem with the Packit format, though it... does need to have the folder stuff added, and also I'd... like to see if we can come up with another internal... compression format that, while not compressing the file... to quite as small a size, would be faster and so... would be practical to implement on the fly. ga (Neil/Sysop) Quick comment: When Ches invented the PackIt routine I thought along the same... lines as Don mentioned; it would be harder for users to understand.... So I did not use it right away on MAUG. That was the biggest mistake I... ever made. PackIt has proven itself to be extremely easy to use and to... understand. I answer from 10 to 100 phone calls a week on the published hot line number. Most are not people confused by PackIt... When we developed the original MacBinary the main guideline was... KEEP IT SIMPLE... both in programming and user interface... I think adding comp/decomp to the actual format might make for too... much of an effort and could result in later problems as newer and.. better comp schemes are devised... CHESLEY:Harry Chesley> OK... Three (quick) points: (1) The PackIt II protocol has been published. Hence the two/three public domain unpacking programs available. (2) If you, today, upload a PackIt II file without using MacBinary, and then download it and unpack it, everything works fine. The only thing you loose is the ability to double-click the downloaded file to invoke PackIt. That is, the info in the MacBinary part of the file is entirely duplicated in the PackIt part. (3) The terms "protocol" and "format" are not so clearly defined as people have been implying. Generally, a protocol involves a format and what to do with it/ in response to it. We're used to thinking that MacBinary is a format and XModem is a protocol because XModem is more "active", but really you can consider them as separate layers in a larger protocol stack. Anyway, it doesn't really matter. There's no well accepted reasons for placing different functionality at different layers, really. It's mostly just what works. (Gustavo A. Fernande) I agree heartily with ches regarding protolocol layers and the duplication of effort between MacBinary and Packit. Obsticles to using Packit. 1) Not public domain. This is a problem and it is high time that someone write a public domain packing side of Packit. Sorry to put Ches out of business, but I don't think its all that hard. (Neil/Sysop) Gus, there are at least 3 such programs. UNPIT packs. (Gustavo A. Fernande) 2) Effort - along with the public domain standard should be a public domain implementation - of the PACKING algorithm, neil... Anyone could insert this code into whatever terminal program they have. (Gustavo A. Fernande) This also eliminates the possibility of of subtle interpretations of the standard. (Sorry, my mistake, neil...) 3) Time. It is a fact that at 1200 bause, even doing fast track transfer which usually does a pretty goot job of saturating the comm. link, the Mac spends most of its time waiting on the serial line. Certainly some of this time could be put to good use unpacking the files. At higher rates, a multi-buffer scheme can be implemented which, while more complec, is still doable. (Neil/Sysop) Again, my feeling here is we have to keep it simple in order... to see it programmed in our lifetime..... Just curiosity how about a quick roll call... If you favor comp/decomp in MacBinary type INTERNAL If you favor it outside MacBinary type EXTERNAL (Linda/AltSysop) YES (Larry Loeb/BIX) internal (Donald/Sysop) external (sort of) (Gustavo A. Fernande) INTERNAL PEABO:Peter Olson> INTERNAL (Linda/AltSysop) INTERNAL MACINTOUCH:Ric Ford> INTERNAL CHESLEY:Harry Chesley> external (Yves) External (William Bond) external BMUG:Raines> InternaL (Tom Evslin) none of the above CHESLEY:Harry Chesley> (but...) AESOP:Laird Heal> internal NWOLF:neil wolf> INternal (Neil/Sysop) OK, let me just interjedct something... It's important that the major authors of the PD programs.... hat support MacBinary favor External at present. (Scott Watson) First of all (and with tongue in cheek), I'd like a second... role call of those who typed INTERNAL and are authors of... a telecommunications program. (Just kidding, don't do it). But seriously... I think I'd like to make it clear that I'm not opposed... to standardizing things like comp/decom and multiple... file packing. I just want to make a strong warning that we... not confuse those features with "MacBinary" format, which... has an entirely different function. "MacBinary" does need... a little patching for the new Finder bytes, but one of the... reasons that it can be called a "standard" is because it's simple. I really think dilution of its function would be... a bad mistake. The point that Harry made about not being... able to double-click on the dl'd PIT file that was not... MacBinary formatted underlines exactly why we came up with... MacBinary in the first place - _don't_ make assumptions... about the relative experience of the receiver to figure... out that he needs to first run PackIt, choose Open from... under the File menu, etc. Harry's point that what is... important is "what works" is well taken. I haven't seen... it demonstated that MacBinary doesn't work, so I'm still... wondering why we're trying to "fix" it. Finally, Don said... earlier that "PEOPLE WANT COMPRESSION". I would with... all respect disagree. People want something for nothing. They want to receive a 128K file using a $50 300 baud modem is 30 seconds. OK, we know that that's not practical, and comp/decomp can certainly... add some savings of time. But again, I underline that... you _do not_ "add" comp/decomp to MacBinary, or XMODEM, or... any other standard that is in place. If we want comp/decomp... (which I think most of us really do) - then we go after a _new_ standard which does not interfere... with either the protocol or the MacBinary format. GA. (Neil/Sysop) I tend to agree, I calkled this meet to "fix" MacBinary as the sdtandard it is. Don was next. Go Don. (Donald/Sysop) First, I'd like to point out that even agreeing now to... "External" unpacking, this does not preclude a program from... deciding to recognize Packit II files, and unpack them... on the fly. (In fact, anyone who added such a feature to... their program would convince me to switch on the... basis of that feature, probably.) So, there really isn't... any need to build in a compression/packing algorithm... now. So, it's sounding as though we just have to decide... how to implement the new finder bits. (Yves) Well, I had the same idea as Don,... The Xmodem routines feed of the serial port, the MacBinary routines feed of the Xmodem routines and the unpacking routines feed of the MacBinary routines. The good old layers again. All we have to do now is... decide on a "MacBinary" standard, then later we can decide... on a packing standard (I would go for Packit). ga PEABO:Peter Olson> on the issue of public domain vs. not ... I think that it is crucial to have a public domain source code ... for any compression algorithm we decide to recommend ... but I don't that that necessarily means that we are ... taking anything away from Harry ... since UNPIT etc coexist peaceably with PackIt at present ... the value in a particular shareware package lies in the ... implementation, not the algorithm used for the bitlevel stuff ... one thing that would be very distreessing would be to see a ... packing war aride in the Mac community like what has happened with ARC ... where people are constantly trying to shave a few percentage points ... the value of recommending a compression standard to go along ... with MacBinary is that it gives terminal program developers ... a chance to put features like on the fly inpacking ... into their programs without fear of obsolescence ... we coule imagine also distributing ready-to-go code that would ... fit into a terminal program much like the Mac menu definition proc fits into Mac programs. ... and finally ... even though we might not want to come out stringly for ... internal unpacking now, if we made the recommendation of PackIt ... we would have the opportunity for terlecomm developers ... to introduce on the fly unpacking gradually, just ... like was done with MacBinary itself, and ... a year from now it might be taken for granted. (Neil/Sysop) As I read this I think we may, I say may, have a consensus. It seems that we more or less agree now that... MacBinary in and of itself should not contain a comp/decomp... algorithm (like now) but that we should informally recommend the... PackIt format to terminal program authors who would wish to... incorporate such bells and whistles into their own programs. And, by the way,m Don Brown has messaged me that he would put his own Unpack source code into PD. (Scott Watson) First, I would advise against making an informal... recommendation for any given decom algorithm until... we have had an opportunity to look it over, suggest... improvements, and formally agree on a standard. I'm... not suggesting that there's anything wrong with Harry's... format in PackIt, but to be frank, I've not had a chance... to examine it, and misunderstood the purpose of this... meeting to be for the MacBinary header only. I suggest... that those interested in a formal packing standard take... a week to give it the coder's eye, and come back prepared... to begin discussions on that next Sunday. Please... understand the intent of this suggestion - a good standard... that will stick should not be accepted simply because of... it's inertia. If some minor (or even major) changes... were in order, Harry and the public domain authors would... have the opportunity to revise their programs (whereas the... newcomers would be working only on the new standard), and... we would have an untrademarked name of a public domain... standard that we would all be free to use and include... in our code. My hesitancy is based on whether or not.. the scheme Harry uses can actually be used "on the fly". As it hasn't yet been done, I think we should make sure... that the accepted scheme in fact won't impose on the... timeout restrictions of some protocols before we go... putting our stamp of approval on it. Think kew and GA. (Tom Evslin) I agree with Scott that we should get on with finding room in the header for the extra finder bits and postpone packing suggestions for... a later co. When we do discuss packing, I think we ought to... at least consider that the host has a possible role... I should be able to upload (for the sake of argument)... with the best packing algorithm that the host and I agree on... and a downloader should be able to download unpacked... or packed with a different algorithm. This is especially important... because the state of the art in packing does change faster... than people change terminal programs and because there is... typically one uploader and many downloadsrs. GA. (Neil/Sysop) I know we have some people in the queue but... as moderator I would like to try to move this... if we can... (Larry Loeb/BIX) First, congratulations to Peabo on getting... two serial ports to work together Nice hack;and I'm glad to see the Delphians here. Next: I have two hats here... One as a moderator of a system.. and the second as an author of a mac to mainframe... commercial program still being developed. When we talk about decomoping on the fly... remember that life is more complicated at 19.2kb than at .. 1200. I dunno how much overhead (Or ,for that matter..) how much compression packit will give.. maybe harry can tell us at some point... I know that from the MacNifty digitizer days that Huffman encoding does save space and is doable on the fly. It is also PD. As a system person; I want to save diskspace.. on the system as much as I can.. and I want my users feeling they.. are getting as much as they can from it. But: we must do this later. Let us NOW decide what to do about the flogging Finder bits so that a file sent from desktop dont blow things up MACINTOUCH:Ric Ford> OK There are some real fine programmers here. And I haven't given as much thought or as much effort to the telecomm. cause. The consensus seems to me to be "keep the separate levels" and the essential, near-term problem seems to be "What attributes (flags/bits) does a file have on the (Finder) desktop... Is this an Apple vagueness? Can we get it defined? Can we plan now to be ready for future Apple/Finder changes? (Neil/Sysop) You took the words out of my mouth.... DO we have a general feeling now that the comp/decomp issue is a... separate issue and that we should move onto the Finder bits? Anyone disagree?? CHESLEY:Harry Chesley> I am looking at this issue from two points of view. First, as the publisher of PackIt, I'd definitely like it if the outcome of this meeting was to simply tweak the MacBinary protocol. That makes the most money for me. On the other hand, I'd like to see the best protocol we can get. From that point of view, it seems a real shame to move to a new MacBinary version, with all the attendent compatibility/upgrade problems without extending the protocol to handle other features. (Although I do think it should always be optional for the receiving program to do the file decoding on-the-fly or to leave it for a post-processing program. However, since it's in my financial interests to leave the world the way it is, I'll just bring this point up and not belabor it any more. (Jack Brindle) First, on compression - I fully agree that it does not belong in the formatting. I do believe that it belongs in the transport protocol. In fact, there is no reason that Scott (or Yves, or whomever) could not add a compression/decompression layer between the MacBinary formatting MAUG (or wherever), only users would either require Scott's program or a decompression application to use the file. After looking at Harry's Packit Spec, I really would like to see someone do an "on the fly" coding. I believe it would take lots of Memory and some execution time. Since Harry has coded it, perhaps he has some insights. Now about multiple file transfers... We could adopt X.225 and solve the whole problem with multiple sessions. Or perhaps Yves could release his session layer protocol... After looking over Yves' doc, it looks pretty good to me. I question the need for full CRC on just 128 bytes, I believe that if error detection is needed (remember, it is done by the transport mechanism), then perhaps a simple checksum would suffice. XMODEM needs CRC since it is a transport mechanism. MacBinary, which could make use of the XMODEM (or other protocol) error detection does not really need one of its own. Remember too that the two file forks do not have their own CRC/checksum. Oh yes, Larry's 19.2 comments are pertinent. MacPacket will soon be operating over Ham Radio at 56KB. That doesn't give much time to do anything. (Neil/Sysop) I think it is very important that we move onto the Finder bits... part of the discussion as it seems that we all agree that the... discussions as to packing/unpacking are really separate at this.... point from discussions as to fixing the MacBinary Header. Do we... all agree that we should, at this point, turn to the problem of... these Finder bits? Anyone disagree? ga (Gustavo A. Fernande) Lets talk COMPATIBILITY Are we shooting for complete upward compatibility or complete non-compatibility with new programs having to support two completely different file formats? If we want upward compatibility, is there a way that we can guarantee that the newly used fields in the MacBinary II header will not be misinterpreted by old programs or rejected as a bad file. Secondly, we should not limit our discussion to just the Finder bits. We should look at encoding as much PBGetCatInfo information as possible. (Neil/Sysop) We do need upward compatibility but not downward... in other words... a term program with the "new" MacBinary had better be able to download all.. the trillions of "old" MacBinary files! (Yves) Since we're going to have a break,... I'd like all the people that don't have the draft 2 of my proposal.. to download it (it's only a minute's worth) so we... can start the second part of this CO constructively. it is in DL6, top file (just type BRO). (Neil/Sysop) Let's take a 5 minute break and meet back here! <A recess was held, with some farbling continuing> CHESLEY:Harry Chesley> (I have to get going. So I won't be back after the break, I'm afraid.) (Neil/Sysop) Harry, OK this will be uploaded to all nets. See you all in 5 (William Bond) Can I suggest my file bin2.txt (Jack Brindle) Yves? (Yves) Yes (Jack Brindle) Did you get my comments about CRC in the header? (Yves) Yes, but I have to say that a CRC routine... is only about 8 lines of assembler. (Jack Brindle) yes, I understand. Just wondered what it added. Much faster to run than compression!!! (Yves) CRC is almost instant in assembler. and it's error proof. (Jack Brindle) well, it looks good otherwise. My question abt CRC came up due to the lack... of it on the two file forks. Perhaps it should also be added their (YUK!) (Yves) I don't think so,... if the header is clean, we can assume the rest will be! ga (Jack Brindle) Well, the transport mechanism guarantees it will be clean! ga (Yves) Remember the 7 bit stripping problem? ga PEABO:Peter Olson> yes, but the transport is only one link in the entire ... end-to-end path ... the CRC in the header is designed to detect ... an error if that kind (like uploading a file in the wrong format) (Jack Brindle) two valid points!... The 7 bit problem could be resolved by defining a byte that must have bit 7 set. The CRC does fix some problems with recognition falsing (I have seen that a few times). You've convinced me! ga (Yves) Have you read the bit meaning of my "options" field? ga yes, but that comes out of the receiving end. didn't realize the xmitter coded it. ga (Yves) did you get my answer? ga (Scott Watson) Have we resumed? (Yves) Not yet! (Jack Brindle) what is the problem with the current format? (Donald/Sysop) Jack, we're missing at least eight bits of finder flags,... and there may be something useful in the extended finder info too. (Jack Brindle) ok. one other question - will the 'MAC2' format mess up on the OLD ROMS? (Yves) I don't understand? (Jack Brindle) well, think of the prro guy that has a 128 (shudder - there are still a lot of them). Will the proposed upgrades work without problems under the original ROMS? (Neil/Sysop) OK... I think we should resume.... (Larry Loeb) [back] (Neil/Sysop) I hope we've all read the files.... (Yves) It is in no way linked to the roms <And the meeting was again called to order> (Neil/Sysop) Now let's switch over to talking about the Finder bits! Floor's open who has comments?? (Scott Watson) My gut feeling is that we _can_ extend... the MacBinary header to include the new... information and maintain compatibility... with the old standard. This would be the... best of both worlds as it would not... obsolete (can that be used as a verb) all of the existing... telecom software. We built in 29 bytes of... "reserved" data with just this sort of... thing in mind. Lastly, I really hope... we can decide on the new standard based not... on creating a "carbon copy" of the Finder Info on... the source disk, but by concentrating only on... those bits/bytes that would always remain... constant when copying a file from one... disk to another using the Finder. In other... words, make no assumptions about the layout... of the receiver's disk and don't go creating... any folders. GA. (William Bond) My suggestion in bin2.txt attempts... to be compatible with old MacBinary... unless I read it wrong I don't Yves is... We need to decide whether we want to be compatible... I will try to upload a segment for those who.. haven't seen it.. hold on... 1) Offset 125 of header - since offsets 0, 74, and 82 must remain zero for compatibility with existing programs this will become the "version byte". "Versions" of MacBinary 2 will start at 129 (high bit always set). Programs that support MacBinary 2 should check this offset for a non-zero value to determine if the file has been sent using MacBinary 2. It should also be verified that the high bit is set to protect against hosts that may have stripped the high bits from the file. 2) Offset 126,127 of header - a CRC of the preceding 126 bytes of the header calculated using xmodem conventions. This is further verification that the file is indeed a MacBinary 2. 3) Offset 99 of header - new Finder information. It must be determined exactly what is necessary here. (Yves) I discussed that matter with Neil and the conclusion... was that new decoders must understand both the old and... the new format but that old decoders must reject new... files. (Neil/Sysop) Comment.... I am not a programmer..... If it IS possible to have complete..... both-ways compatibility that might be a good idea. (Yves) If you let me finish... an old decoder try to decode a newly encoded file,... you end up with a PARTIALLY valid file, you risk data loss... and unpredictable behavior of the file/application. (Scott Watson) First, let's talk about what needs to be included that isn't there... and then let's decide on the issue of maintaining compatibility. PEABO:Peter Olson> I think it would be helpful, for downward compatibility ... to distinguish between new finder bits that are vital to ... correct transmission of the file (like "Shared") ... and those which are only cosmetic (like "On Desk") (Tom Evslin) I think we can have up and down compatibility - and should... If we follow Scott's suggestion, I think we'll find plenty of room... We obviously don't need to know if the file is open on the sending sys... We do need to define defaults for attributes like shared when... a MacB II program downloads a MacB I file... The attributes need to be the "safe" choice such as can't be shared. (Donald/Sysop) Unless I'm forgetting something, all the current flags are... missing are some flags that, while useful, are not necessary. ... For example, we're missing a bit for switching (which the... user can get around by booting off of the floppy instead... of running on the hard disk), sharing (which means that... applications can't be shared), etc. Think of how many... people we run into who are still using MacTerminal 1.1,... and how much trouble we have with those people trying... to download stuff. If we introduce an incompatible... file format, we're gonna get hung--and I think with good reason. (Larry Loeb/BIX) agree (Scott Watson) _Please_ tell me the potential damage or unreliable... performance that could occur if the extended bits were left as... zero (as current MacBinary suggests). Outside of bit #5 (bfAlways: always SwitchLaunch), I find nothing that... could be called "unreliable" and I really don't see... where data loss could occur if these were all zeroed... OK - here's my question. I'm still unsure what's... broken (unsure, unconvinced - either/or/both?)... Both of the proposals have merit, I'm sure, but... they don't spell out to me the problem that... requires the solution. Enlighten me? GA. PEABO:Peter Olson> yes, "Always switch launch" is the real killer ... and the problem is that we already have a few files that need it ... in the licensed sowftare from Apple ... it may be that the only solu?]ion there is to have a program like ... Don's fixup program that takes care of it (in that specific case) (William Bond) For scott... trying to address a couple of things... 1) incorrect identification of some "foreign" files as macbinary... 2) identification of high bit loss on some hosts... 3) addition of the additional finder bits (Donald/Sysop) Can someone who has Inside Mac Volume IV check out the... extended finder info? I think it doesn't have any information... we'd want to send, I think it's just the folder to put away... to, the resID of the finder comment, and other such things,... but someone should make sure. Also, when we put in a new... Version number, I'd suggest two version numbers, a "Version... number that wrote"... the file, and a "minimum version to read", so that if... we come out with a MacBinary 2.1, MacBinary 2.0 can tell... whether or not it can make sense of it. And, also, yes, one byte in what we put there should... have the high bit set, although it may be too... late, because that might well mean it would be interpretted... as a MacBinary I file. (Larry Loeb/BIX) Don: do you mena that if that high bit WAS stripped.. that mcB one would think that it was a mcB one file? (Donald/Sysop) I guess I mean it more as a question, how can... my terminal program tell the difference between a... bad MacBinary II file that had its high bits stripped, and a... good MacBinary I file that didn't set that high bit when uploaded? ga (William Bond) One of the reserved locations... is defined to be a byte... that has both high and low bytes... set. We know it is Bin2 beacuse... the byte is nonzero whether the... high bit has been stripped or not (Scott Watson) This is wild shot into left field, but has... anyone checked to see if one of the bytes in... the Creation Date field would have the high bit... set for files created in, say, the last decade or so? That would be convenient, methinks. GA. (Neil/Sysop) At this point we have a p[retty manageable sized group.... Let's try it as an open CO rather than as formal... moderated and maybe it will go better. I will standby and if... things get chaotic I will be brutal as always... But let's try it open to see how it goes... (Tom Evslin) I have IM open PEABO:Peter Olson> the idea of checking the date is an interesting one ... none of the other available fields can be relyied on ... though occasionally you'll see a file that was created by someone who had his battery out (Donald/Sysop) Checking the date is valid--if you assume that the... developer always had his time set reasonable. Do >YOU<... want to make that assumption? (Larry Loeb/BIX) really--but u can check 1904 (Scott Watson) Don - agreed. But how common is the problem we're addressing that we... can't make such an assumption with decent reliability? (Donald/Sysop) Scott, a lot of the older stuff, including some of the... Software Supplement stuff, has that problem. I like Bill's... idea, seems simple and workable. (Jack Brindle) Why not just use negative version numbers? (William Bond) This is easy to add if other things are being done (Larry Loeb/BIX) jack:to test for hight bit? (Jack Brindle) yes. (Larry Loeb/BIX) don: and non-zero (Scott Watson) Don - I'm not against it, I was just hoping for an easy way out (snicker). (Tom Evslin) Back to Don's ear;ier question Nothing in extended finder info looks needed... There is the icon id... four unused integers (which could be used someday)... the comment id... and the home directory id nothing else. (Jack Brindle) Let me say it again, the two's complement of the version would set bit 7! (Donald/Sysop) Yup, Jack, as would starting version number at 129. (Donald/Sysop) What's "icon id"? PEABO:Peter Olson> do you think any of that stuff is preserved by Finder if INIT is zero? (that is when Finder sees the file the first time) (Jack Brindle) don; the resource id of the file's icon. (Donald/Sysop) Peabo, if I was writing the finder, it wouldn't be. (Tom Evslin) icon id is the id of the icon in the desktop file It won't be right on the receiving system anyway. (Scott Watson) I'd feel a lot better about Bill's proposal if he would move things down... into the 27 reserved bytes and stay away from #126 and #127. I _do_ see... a possibility in the near future where hardware/OS might be important. (William Bond) Do we need the CRC too? PEABO:Peter Olson> I'd really like to see the CRC ... it's cheap and will filter out an awful lot of non-macB stuff and as a byproduct, it is *unlikely* (though possible) that a Lotus spreadsheet from an IBM system will happen to hit the CRC on the button (Scott Watson) Is the CRC really for error correction, or just to add confirmation that we... _are_ indeed looking at a MacBinary header? (William Bond) for confirmation ... we assume that the underlying transport protocol is reliable, but we don't ... know what might have happened to the file when the host was storing it (Scott Watson) Then I say what the hell, it can't hurt and it doesn't take much time. (Tom Evslin) good decision. (William Bond) Exactly (Scott Watson) You've seen those bastard .WKS files too, eh? (Donald/Sysop) Okay, I've almost got a "formal suggestion" to present. (Scott Watson) Putting on my tux - go Don. (Donald/Sysop) Okay, here's a proposal. We'll define 5 more bytes: Offset 99-Byte, Other Finder Flags Offset 122-Byte, Version number of uploaded Macbinary (starts at 129) Offset 123-Byte, Minimum MacBinary needed to read this file (starts at 0) Offset 124-Word, CRC of previous 124 bytes (Larry Loeb/BIX) no 126 and 127,eh? (Scott Watson) Larry - 126 and 127 were allocated by the original standard for hardware/OS. (Donald/Sysop) Yup, once again left for computer/OS. PEABO:Peter Olson> and 122 and 123 both have the high bit set, no matter how many versions we invent :-) (Larry Loeb/BIX) two complememt of version number (Scott Watson) That's for when we get a guy downloading a MacBinary file on a Mac II... using UNIX (shudder). (William Bond) I missed that about 126, 127 PEABO:Peter Olson> or would the lowest level that will work sometimes validly be 0? (Donald/Sysop) Larry, why? If you missed the partial lines,... the version number starts at 129. Next rev will be 130, etc. (Scott Watson) Peter - if Don's byte 122 always have the high bit set, why do we need more? And whey you guys propose "MacBinary version 128", I'll move to the Amiga. PEABO:Peter Olson> I just wanted to see a statement about 123, lest the unwary test that as well (Donald/Sysop) Should minimum version start at 129 (our first... version) or 0, since we do make some sense if... downloaded by MacBinary version 0. PEABO:Peter Olson> if it can be zero, we should point that out (not that a MacB I program cares) (Jack Brindle) I vote for -1, and decrement from there. It is consistant with version 0. (Tom Evslin) Do we need hi bit when we have crc? (Donald/Sysop) Tom, if the data was all hi bit off, crc will never tell... if the hi bit was stripped, or am I wrong? (Scott Watson) Tom - sure, there are CRC's without high bits set on both bytes. (Donald/Sysop) Jack, why? (Have I overlooked something)? PEABO:Peter Olson> it might help to be able to say that the CRC doesn't match and in addition, the high bit is zero, as opposed to just the CRC not matching ... (Tom Evslin) But the crc won't check if bits were stripped (Scott Watson) Tom - whoops, now I catch you're meaning. If the high bits are stripped, the... CRC would fail (slapping forehead) - good point. (Jack Brindle) well, either one is easy to do, but it seems more consistant to go 0, -1, -2... PEABO:Peter Olson> this for a human who is examining the file and trying to figure out what went wrong, not for the program to do automagically and as Scott pointed out, when we get to version 255, we should all buy new machines (Scott Watson) Agreed, if the CRC fails, we should tell the user... whether confidence is high or low if it looks for all the world like... a MacBinary header, but the CRC fails. (Donald/Sysop) Okay. The comments I've seen are that Jack would like... negative numbers counting down. Any other suggested changes I've missed? (Scott Watson) Don - have we agreed on what... bits in the new Finder flags to keep and which to always zero? (Donald/Sysop) I don't think that's come up yet. But, I think... if memory serves that everything in the new... flags should be kept except for "On Desk" (Scott Watson) Don - NO! bits 1 and 6 definitely should be zeroed, I think. (Yves) Can I suggest something? (Donald/Sysop) Sure, Yves, speak away! (Yves) How about putting an exact copy of the flags in the header... when you upload and then strip them when you... download. that way the undefined ones will always work. (Donald/Sysop) Yves, agreed! Good point! (Jack Brindle) I like that! (Scott Watson) Wonderful. Tanks Yves. (Yves) It was in my proposal! (Neil/Sysop) Neatly done... (Tom Evslin) right (Donald/Sysop) When downloading, though, we should recommend stripping... bits 0,1,and 6. PEABO:Peter Olson> which bit is which, don? (Larry Loeb/BIX) yves: in proposal you say strip destop and inited (Yves) that you have to reject it in block! (Donald/Sysop) That's OnDesk, OwnAppl, and CurrentlyStripped. In addition,... (Scott Watson) Don - as well as bits 8, 9, 10, and 13 (as always). (Donald/Sysop) Yes, as always. (I was only speaking of the new bits, not the old) (William Bond) Can we leave it for don to work out and post the specifics for comment? (Tom Evslin) bit 6, I think, should be kept... the description is confusing. (Scott Watson) Tom - why? That bit is only significant to the sending machine. (Donald/Sysop) Tom, that bit only represents whether the file is... actually being shared at this moment, I believe. I think... that you actually set/clear bit 7 for saying whether... the file is shareable or not. I did some stuff with those bits, but it was a while ago. (Tom Evslin) That's the way it's described in tech notes 40... but I think it means sharable. (Scott Watson) Don - that's the way I read it. It tells other shared files to not attempt to open it for write access. (Neil/Sysop) Bill's comment seems like it might be the way to go here now... Don can collate this and post it in the next day or so.... and we can continue at a CO next Sunday? Of course anything... posted here on this may, and should, be immediately copied... to the other nets that are participating. Does that sound OK with all? PEABO:Peter Olson> yes! (Larry Loeb/BIX) Neil: What about Usenet? (William Bond) yes (Donald/Sysop) OK. I'll try to get stuff up tomorrow sometime. (Tom Evslin) souns good. (Neil/Sysop) (Larry, yes) (Yves) Can I comment on this whole thing? (Jack Brindle) yes (Neil/Sysop) Yves, go ahead! (Yves) I think what you guys are doing right now is... just "short term patching" while you... should be doing some "long term" re-design. ga PEABO:Peter Olson> what do you think of Don's suggestion of ... MacB 1.5 as specifcally a short term measure (Donald/Sysop) Yves, I don't see >why< we need a long-term redesign? (Yves) It is obvious to me that if it changed, it'll change again. So we So we have to create something that can evolve... in the future while it's still possible. It'll... be too late in a year. The actual format isn't... bad but it lacks a few thing that cannot just be... patched away. It think it's now or never. ga (Donald/Sysop) What are the few things? (Larry Loeb/BIX) what? decomp/comp? (Yves) Don't bring that back, I'm against it. ga (Tom Evslin) I think there is a "simple " way to meet Yves' objection... (Yves) I'm all ears. (Tom Evslin) Add one more bit to say there is a second header block... Have MacB II read that block (even though we don't know what's in it)... (Larry Loeb/BIX) hmmmmmmmmm (Jack Brindle) Yves, the current diffs between your proposal and the one on the table (Scott Watson) Tom - don't think that's necessary, the version number can tell us that. (Jack Brindle) are the signature, version nr (int), and options word. what else would you suggest? (Tom Evslin) Don't have MacB II write it..Scott, it would specifically allow MacB II to read MacB III.. filess without going crazy. (Steve Brecher) (Better to have the size of the header, rather than a bit.) (Tom Evslin) Then although MacB III may obsolete I (one) it won't obsolete two. (Yves) a way that will not allow for downward compatibility? ga I can give examples. (Scott Watson) OK - I think my point was misunderstood... Why have MB II read the second header if it can't do anything with it? It's... very possible that when it becomes necessary to do another MB, the information.. in the second header would be vital. In that case, MB II (and all future... MB incantations) should look at the "minimum MB version number needed to... convert this file" byte, and if it's higher than the version number in use,... no conversion is done in deference to a separate conversion program (like... BINHEX 5 was to non-MB I programs). (Tom Evslin) The new information in the second header may be desirable... but not strictly necessary like the info we added tonite... but there may be no more bytes. (Yves) Can I ask you a few questions? and get answered? (Neil/Sysop) Yves, ask who?? (Yves) The group as a whole! (Neil/Sysop) sure! (Larry Loeb/BIX) shoot (Yves) OK, one question at a time, everybody answers, then the next one. 1)... Should the format handle everything by itself or let the user decide in... case of some sort of a conflict? ga (Jack Brindle) ? (Scott Watson) (confused). (Larry Loeb/BIX) it's mac-ish to give the user choices (Donald/Sysop) What sort of conflict? (Peter Olson/ICONtac) too many interactie dialogs could be a problem ... esp for "unattended downloading" (Scott Watson) Larry - not necessarily. (Neil/Sysop) should be as automagic as possible. (Yves) Let me re-phrase it. (Jack Brindle) But, user's aren't necessarily smart - give them a "hidden" choice with defaults. (Larry Loeb/BIX) scott: thinking of auto-recieve check boxes what if the folder info would overwrite... into the recieving mac... a file with the same name?.. shouldnt there be.. a chance to stop that? (Yves) the answer is definitely that... it should be as independant as possible. Right? (Scott Watson) Yves - right. I don't think it's advisable to start discussing... "Always Switch Launch" bits casually with the user, if that's what you mean. (Yves) No, just a general question. I'ce got a lot more of them. ga (Larry Loeb/BIX) Yves: Yes ASL bits arent for the user (Yves) OK, 2)... I understand that nothing that needs to be included today... is critical but it could be or definitely will be... So, I still don't think we should let a routine that... doesn't know about the new stuff nose around and try to... decode it. It is acceptable today, it WILL not be tomorrow... So, I think that as we move up in the versions for MacBinary... we should NEVER let previous routines try to decode... Here is an example: If one day, we find a way to send the GetInfo comments... along with the file and you let an old routine look at it,... it won't take it (that's the data loss I was talking about)... also, some flags are still not defined it the few word that... are included in the header, what if one is one day given a... critical meaning, then again we have a REAL mess if we let... old routines touch it. Another example, did Apple let old... MFS routines nose around in the new HFS structures when it... came out? No, they just improved their routines and dropped... the old ones. Only the new ones could read both. What... I'm trying to get across here is a spirit, we are trying... to go forward, not backward. That's 2. ga (Tom Evslin) Noone will use the new routine to upload if it can't... be downloaded by all the old routines. (Donald/Sysop) Yves, IF something happens that we need an incompatible... version, then yes, we'll make it so that the old... routines can't read it. But, to lock out every current... user of a current software on the assumption that there... might be a problem someday strikes me as begin Wrong. I... Would suggest, though, that we pick one of the... "To be Zero" bytes now, and decide that it need not be... zero in the future, so that a MBII program can say something... intelligible like "I Can't speak MacBinary that high" as... it downloads it like a text file. (Yves) We're getting there,... (Peter Olson/ICONtac) (like a palin binary file, not a text file!) (Scott Watson) Don - doesn't the version number byte tell us that? (Scott Watson) In other words... (Scott Watson) When we test the block to see if it's MacBinary, we should also test the... version number byte to see that it's equal to or less than our own. If it's higher, don't do any conversion. (Jack Brindle) I have to agree on this point - we now have three version numbers! Let's use the original one to indicate the II version - offset 0! (Donald/Sysop) Let's now ignore byte 82. That way, if we find out that... the next file must not be read by MacBinary I, we can trash... it, but our MacBinary II programs can see that it's... a version conflict, rather than a non-MacBinary file. clear? (Peter Olson/ICONtac) I'm in favor, Don (Yves) OK, my turn again. So, we all agree that eventually, we'll have to invalidate all previous... decoders in favor of one and only new decoder and that it will... happen overnight. The fact it is done thru those new version... numbers or by putting a non-zero value somewhere doesn't matter,... you'll kill everybody! They'll have to use a post-processor for... a certain time. Wouldn't it be better if that happened now... instead of in one year or more. ga (Scott Watson) NO! I don't understand what it is about what we've proposed tonight that... y'all are paranoid about MB I reading. The truth of the matter is that only... 1 bit has been proposed as an addition to actual file matter in two years... the 7-bit and signiture stuff is only for added recognition reliability. (Neil/Sysop) No.... Speaking as a sysop....A post-processor would be a disaster. (Tom Evslin) Version x cannot invalidate version x-1... or all the users refuse version x... version x may invalidate version x-2... if absolutely required. (Donald/Sysop) No, Yves, I don't. It's a possibility, but I think low probability. Also, we don't know enough now to save the pain now. The... fact we'll have to burn everyone a year from now does not... mean we have to burn them now! (Jack Brindle) It is obvious that a switch will have...] to be placed in programs so the user can decide if he wants... to send MB I or MB II. But, I tend to agree that the stuff generated by MB II should not necessarily be readable by MB I. For one thing, the... original spec says the 27 null bytes should be set to zero. We have already changed that. One thing I would like to see would be to use the original version byte as the "new" version byte, instead of the byte at offset 122. the version, then fall back if necessary. ga (Scott Watson) Jack - I agree that the old "version" byte should be used instead of byte 123,.. but the standard specifically says that the 27 bytes are for extensions to the.. standard. Only MB I programs should explicitly zero them. (Neil/Sysop) If the new files CAN be readble by old standard they SHOULD be (Peter Olson/ICONtac) how do you solve the problem of an orderly conversion to the new standard? (that was to Jack in ref to a new "byte 0" version number) (Donald/Sysop) Scott, Jack, are you volunteering to answer every... message of people asking why the software they've downloaded... from CIS/GEnie/Delphi won't work? If we don't have to break... every terminal program out there, why on earth should we? (Jack Brindle) Wait a minute... (Yves) I have more for you, just tell me when! ga (Larry Loeb/BIX) sell *new* term progs (Scott Watson) Don - I agree! All I'm saying is that the most catastrophic thing that... (Jack Brindle) We currently have a problem due to the inability to read certain crossloads... (Peter Olson/ICONtac) larry, you'll be burned in effigy, if not reality, for that (Larry Loeb/BIX) peabo: you missed the tongue planted in the cheek (Scott Watson) could happen if a MB I program downloaded a MB II program as we've proposed, the "Always Switch Launch" bit won't be set. (Peter Olson/ICONtac) scott, not many files (*yet*) need to do that ... I think we would have to be aware of that kind of problem for some time to come (Donald/Sysop) Scott, I couldn't agree more, except that the most... catastrophic thing that could happen is if we set up... the MBII header so that a MBI file will make a text file out of it. (Yves) Can I go on 3? ga (Scott Watson) Don - before I agree to that, tell me... what the worst is that can happen if the ASL bit should be set but isn't. (Jack Brindle) Hey Scott, did I hear Don volunteer free PPNs a minute ago (grin)... ga (Donald/Sysop) No, Jack, you'll answer the questions on your own account. (Donald/Sysop) Scott, a few programs won't work right, like the Installer... will complain. (Peter Olson/ICONtac) for those few files that need ASL, we *have* to give instructions or have a ... fixup program. (Jack Brindle) Like Yves, I see problems if we retain backwards compatibility. GA Yves. (Tom Evslin) We're not \living in the real world... if we don't mantain backwards compatibility when we can. (Neil/Sysop) (Tom: I agree) (Yves) 3 I guess then... It is obvious to me that none of the developers are accessing... the serial port thenselves. This is because of two things: first: there is a package for that called the serail driver. Second: That way, it is always compatible. I think we I think we are facing the same problem here... There should be a package that everybody... would call in order to do the conversion... and that package would be updated everytime... the format is changed. How about getting... together and write such a package that all... the "MacBinary compatible" softawre would call... and that we would update everyonce in a while... whenever needed. That way, we can do just about... everything we want to the format, because as soon as... we have the new resource, people get it and merge it... in their favorite telecom softawre and there they are... instantly compatible with the latest. How about setting a group an maintain it. ga (Peter Olson/ICONtac) I'm in favor, Yves. (Scott Watson) Yves - I have two comments on that... First, I think you will find that the commercial software people would... be extremely hesitant to include foreign code in their software after the... first time a bug gets by. Who is going to write this package and insure that... it does what it purports to? On that note, I have a burning question I'd like to ask about any new standard. May I? (Jack Brindle) Sounds like a good use for a Package. (Yves) How about a PD downlad DA (like TurboDL) that would use... that package so people can start right away... even if their favorite soft isn't using it yet? ga (Peter Olson/ICONtac) scott, do you do your own menus, or do you use MDEF 0? (Neil/Sysop) I think it would be IMPOSSIBLE to sell that idea... to the commercial arena. If it came from Apple, maybe. From us, never. (Jack Brindle) I agree, Neil - it must come from Apple! (Scott Watson) Peter - what he said. (Peter Olson/ICONtac) hmmm ... could we possibly get Apple to sponsor/certifiy it? (Neil/Sysop) Hardly possible... Apple is not setup to act in that manner... I think we might be a little off topic.... which is to restructure the header NOT the delivery mechanism. (Tom Evslin) Scott's right on both counts.We have a standard... people use it... They like it because they don't have to think about it... We just need to update it as quitetly... and unobtrusively as possible. (Scott Watson) Neil - I've got a burning question about obsoleting MB I programs before we... go any further. (Neil/Sysop) sure, go Scott (Scott Watson) Who is here representing inTouch, SmartComm, MicroPhone, and MacTerminal? We... (Larry Loeb/BIX) Not Dennis (Neil/Sysop) (Jean Hess was here earlier) (Scott Watson) can propose new standards all night long that push those guys out in left... field, but one thing is for sure. MacBinary I became a standard because of... unanimous support. The MacTerminal 1.1 method has all but died because of... a lack of it. (Neil/Sysop) Let me just comment... as MAUG's Chief Sysop for a minute.... I know that we must, if we can, make certain that we do not... obsolete existing terminal programs with a new standard.... If we do it will cause two problems that will prove... insurmountable... The first is that we will be inundated with... literally thousands of help messages... The second is that... people will become very pissed off and simply refuse to use the.... new standard. I feel very strongly here that whatever we decide... MUST LOOK TRANSPARENT to the users we have now. As Scott says, we can only keep a standard a standard as long as it proves... grass roots acceptable. If we lose the people we lose... the standard. <done> (Larry Loeb/BIX) [wild applause from the bleachers] (Scott Watson) Right! The "Lowest Common Denominator" theory is very applicable here... (Donald/Sysop) Agreed. (Peter Olson/ICONtac) yes (Scott Watson) How many developers ship software on HFS formatted disks? (Larry Loeb/BIX) [raising hand] (Jack Brindle) Not I! (Neil/Sysop) Go Yves (Donald/Sysop) Uh, I do, Scott. (Neil/Sysop) Yves, comment?? (Scott Watson) (Don - even the products that are MFS compatible?) (Yves) Agree, but one comment. ways but I think that if we could evetually... put such a package in place, we could then... change the format to a cleaner, better state... without hurting anybody. So I bend for now... but I'm still there lurking. ga (Neil/Sysop) Yves, let me just say... that the idea for such a package is brilliant in concept... The problem is simply that it would require a real... funded organization to lobby other companies and... to adequately support it. Maybe someday! (Yves) Or to get Apple involved. ga (Jack Brindle) Can we take another look at the current proposal? (Donald/Sysop) Jack, I'll be posting the version momentarily. You want... me to dump it here now? (Jack Brindle) Well, specifically, what is in byte 99? (Donald/Sysop) Finder Flags low byte. (Jack Brindle) What is wrong with leaving it in the FInfo record? (Donald/Sysop) Jack, because that's one of the bytes that many... programs check to see if is zero, for determining... a MacBinary header. (Jack Brindle) Ah - they are not Macintosh system compatible - their bug!!! (Neil/Sysop) Don, et. al. it is getting late... (Peter Olson/ICONtac) (no, it's a bug in the MacBinary I spec) (Neil/Sysop) Can you (Don) upload the current state of the... proposal and we can schedule the nedxt CO? (Donald/Sysop) Jack, that's the bug that is why MacBinary needs updating! (Donald/Sysop) Neil, it'll be in a message in about five minutes. (Neil/Sysop) Don, OK but archive it in the DL too. (Scott Watson) Don - please upload it as a file, also. (Neil/Sysop) Is next Sunday OK with all?? (Larry Loeb/BIX) yeah (Peter Olson/ICONtac) yes (Donald/Sysop) Okay, Scott, will do. It'll go in DL6. Also, the... unpacker source too. (Jack Brindle) Field Day weekend, oh well, yes! (Donald/Sysop) Sure, Sunday's fine. (Tom Evslin) I may be away but will respond beforee if so. (Larry Loeb/BIX) don: is unpacker pd? (Donald/Sysop) Larry, yes, it is. (Scott Watson) Neil - can you act as impartial third party to try and get some of the... companies I mentioned to be here for the formal acceptance? (Neil/Sysop) Scott, yes I will try! (Donald/Sysop) My only concern would be Software Ventures, who... might try something, since they've got their own... MB extension. (Neil/Sysop) Well, any closing comments from anyone? I just want to say... thanks to all for being here!!