TweetFollow Us on Twitter

Protocol Standards
Volume Number:2
Issue Number:1
Column Tag:Mac Meets Ma Bell

Protocol Standards

By Bruce Lieberman, Communications Engineer, MacTutor Contributing Editor

Mac Binary Standard

A file transfer protocol specific to the Macintosh that originated within the MAUG (Micronet Apple Users Group) on Compuserve has gained widespread acceptance and is becoming a defacto standard, and is a primary feature of the new MacTerminal 2.0 being distributed this month.

The "MacBinary" protocol (everything earns a label nowadays!) allows transmittal of the Data and Resource Forks within a Macintosh application and it also transfers the Finder information on that particular file ( icons, creation date, size, "About" info, etc...). This standard is now being utilized by virtually every Macintosh communications software developer that I have contacted. Look forward to new versions of MacLine, inTouch and Smartcom that will support the "MacBinary" XModem standard by the time this article is in print.

Here is a reprint of the technical aspects of the MacBinary protocol, courtesy of Dennis Brothers ("MacTep" fame) :

The binary format described is independent of the communication protocol used to accomplish the transfer, and assumes only that an 8-bit transparent transfer can be accomplished. Such protocols as Christensen (usually referred to as XMODEM or MODEM7), Kermit, and CompuServe A or B meet this requirement. Because of the proposed standard's MacTerminal/XMODEM heritage, there is a requirement that the transmitted data be padded (with nulls) to a 128-byte boundary at certain points, but this in no way implies that a block-oriented protocol must be used. The basic format proposed is identical to that used by MacTerminal, by Mike Boich and Martin Haeberli, and can be used with a version of MacTerminal that has had a patch applied to "normalize" its implementation of the XMODEM protocol.

In brief, the binary format consists of a 128-byte header containing all the information necessary to reproduce the document's directory entry on the receiving Macintosh; followed by the document's Data Fork (if it has one), padded with nulls to a multiple of 128 bytes (if necessary); followed by the document's Resource Fork (again, padded if necessary). The lengths of these forks (either or both of which may be zero) are contained in the header.

The format of the 128-byte header is as follows (offsets and lengths are given in decimal):

Offset Length Contents

000 1 Zero. This is a "version" byte.

001 1 Length of filename.

002 63 Filename (only "length" bytes are significant).

(the following 16 bytes are a standard Finder Info record)

065 4 File type.

069 4 File creator.

073 1 Finder flags:

Bit 7 - Locked.

Bit 6 - Invisible.

Bit 5 - Bundle.

Bit 4 - System.

Bit 3 - Bozo.

Bit 2 - Busy.

Bit 1 - Changed.

Bit 0 - Inited.

074 1 Zero.

075 2 File's vertical position within its window.

077 2 File's horizontal position within its window.

079 2 File's window or folder ID.

(End of Finder Info)

081 1 "Protected" flag (in low order bit).

082 1 Zero.

083 4 Data Fork length (bytes, zero if no Data Fork).

087 4 Resource Fork lenth (bytes, zero if no R.F.).

091 4 File's creation date.

095 4 File's "last modified" date.

099 27 Zero fill (reserved for expansion of standard).

126 2 Reserved for computer type and OS ID

(this field will be zero for the current Macintosh).

Note that it is the responsibility of the receiving terminal program to resolve file name conflicts, generally by somehow modifying the name of received file if there already exists a file with the original name on the target volume.

Note also that, while the original window or folder ID and position may be transmitted, the receiving terminal program would not normally set these items for the received file, but would instead accept the values that the File Manager assigns when it creates the new file.

It is suggested that Macintosh terminal programs implement two modes of protocol transfer: text and document. Text mode is used for unformatted files of type TEXT (with only a data fork), and document mode (using the binary format proposed here) is used for all other files. Document mode may also be used on text files, of course, if it is desired to preserve such things as the file's creator ID or creation date.

The intent of text mode is to provide compatibility with text files on other systems. Toward that end, it is recommended that a linefeed be inserted after each return character as the text file is transmitted, and that, in the case of block-oriented protocols, the last block be explicitely padded with nulls if the text does not end on a block boundary. When receiving in text mode, linefeeds and trailing nulls should be stripped. If a CTRL-Z (Hex 1A) character is received following all other text (and before any null padding), it should also be stripped (Ctrl-Z is a common text terminator on CP/M and some other systems). Note that the above discussion applies only to text files transferred under some protocol, where an exact image of the transmitted data will be stored in a file on the remote system.

When receiving a file via a protocol, a terminal program may distinguish between text and document modes by examining bytes 0, 74, and 82 of the first 128 bytes received. If they are each zero (and at least 128 bytes have been received), then it is a safe assumption that a MacBinary-formatted document is being received. Terminal programs implementing possible future versions of the proposed standard would, of course, accept an appropriate set of version numbers in byte 0. Note also that compatible extensions of Version 0 of the proposed standard are possible (one such is suggested below) that involve transmission of additional information following the information described here. For this reason, a terminal program should be implemented so as to perform the proper receive procedures for all data sent to it, but to ignore any data that it does not know what to do with.

Since a text-mode document does not contain a file name, it is suggested that when text-mode is detected, a file be opened under a dummy name on the receiving Macintosh, the text written to that file, and the file renamed to a name selected by the user (via an SFPutFile box) after the reception is completed. This will avoid problems caused by indeterminate delays for name selection at the beginning of the file transfer.

It is desirable to allow the user to specify the destination volume in advance of the actual start of transfer for either type of transfer. Two methods are suggested for this: provide a "Select Destination Volume" menu selection, presumably in the menu containing the "Receive File" selection; or query the user immediately after the "Receive File" menu selection is made. Either or both of these methods could be implemented in a given terminal program - the independent "Select Receive Volume" method is particularly desirable if the ESC-a/ESC-b automatic receive facility (see below) is implemented. The volume selection procedure should provide the same functions as the volume selection portion of the SFGetFile and SFPutFile dialog boxes.

First Proposed Extension

It is proposed that the binary format described above be extended to allow the transmission of descriptive text with a Macintosh document (specifically, the descriptive text from the Finder's "Get Info" box for the file being transferred). This is to be accomplished in a transparent manner by assigning bytes 99 and 100 of the header described above to be used to hold the length of the descriptive text (or zero, if there is none). The descriptive text, if any, will begin on the 128-boundary immediately following the Resource Fork, if present, else the Data Fork, if present, else immediately following the header if neither fork is present. It is hoped that methods for reading and setting a file's "Get Info" text will be made public at some point.

Notes on MacTerminal's XMODEM implementation, and a proposed extension: Familiarity with the Christensen (XMODEM) protocol is assumed in the following discussion.

When doing "Mac-to-Mac" transfers, using the binary format described above, unmodified MacTerminal does not use a true XMODEM protocol, and is therefore incompatible with most non-Mac systems. The differences lie in two specifics: the transmitting Macintosh initiates the transfer by sending the the two characters ESCAPE (hex 1B) and "a" (hex 61); the receiving Macintosh is expected to reply with the character ACK (hex 06). The transfer then proceeds using normal XMODEM procedures, except that each of the header and the two forks (if present) is treated as a separate XMODEM transfer, with the transmitting Macintosh waiting for a NAK (hex 15), then sending the blocks of that phase (beginning with a block number of one), then sending EOT (hex 04) and waiting for an ACK (hex 06) from the receiving Macintosh.

It is proposed that a modified procedure be accepted as a standard, to be implemented instead of or in addition to the above-described MacTerminal "Mac-to-Mac" protocol in complying terminal programs. The modified procedure, which is compatible with standard XMODEM implementations, functions as follows: The transmitting Macintosh sends the two characters ESCAPE (hex 1B) and "b" (hex 62). The receiving Macintosh may optionally reply with ACK (hex 06) (this is allowed so as to have minimum impact on existing MacTerminal-compatible implementations). The transmitting Macintosh then awaits receipt of a NAK (hex 15) (or optionally a "C" (hex 43), if the receiving terminal program supports CRC checking), following which a single, normal XMODEM transfer occurs. The transfer may be in text mode or document mode, will begin with block number one, and block numbers will increment uniformly (modulo 256) throughout the transfer.

It is expected that a patch to MacTerminal making it compatible with the above proposed procedure will be available in the near future.

Responses to proposals

Please address comments or questions on the above proposals to:

Dennis F. Brothers

197 Old Connecticut Path

Wayland, MA 01778

617-358-2863

CompuServe: 70065,172

Delphi: DBROTHERS

MCI Mail: DBROTHERS

New Communications Programs

Presently there are a number of new programs that incorporate MacBinary, including Red Ryder 6.2, FreeTerm 1.7, Telescape & VersaTerm. The proliferation of new Communications software for the Mac is truly amazing ! Most of these are very functional and flexible pieces of software. Most incorporate command languages for unattended functions, multiple terminal emulations, etc. Others have nice little features that make you wonder how you ever got along without them. Like the "view file" function from within the "inTouch" program that allows you to review a file (ascii or vidtex) before it is sent or after it is captured; or the pull down menu in VersaTerm that allows you to store 8 of your most often called numbers and just CALL them without going through all kinds of hassle to pull up a new file. I guess a dream program would synthesize the best features of all of these programs, but right now it isn't as hard to accept what is available as it was a little earlier in the life of Mac communications.

Our next few areas of discussion deal with some of the latest developments in telecommunications : 2400 baud modems and some of the new protocols for higher speed data transmission.

"V.22 bis" is the defacto international standard for 2400 baud full duplex asynchronous data communications. Currently modems from Racal Vadic, Hayes, U.S. Robotics, Novation, AT&T and Microcom support this standard. It is a creation of the CCITT and as has earned the stamp of approval from Bell. The CCITT is actually tied into the United Nations and it produces recommendations for communications standards in the "X" and "V" categories. The "X" series (such as the X.25 standard) applies to packet switched networks such as Telenet, Tymnet and Uninet. The "V" series applies to ordinary switched telephone lines; the 1200 baud standard is V.22 and the 2400 baud standard is now V.22 "bis" (which is French for secondary, kinda like the European version of revisionitis). In the USA there are some slight modifications made to V.22bis to accomodate some of our own domestic quirks, ie: switching between Bell 212a and V.22bis (rather than V.22); and with call-waiting as a widespread feature they have changed the loss of carrier disconnect delay from 40-65 milliseconds to 600 or more milliseconds.

Telephone circuits normally have a frequency bandwidth that is limited to around 300-3000 cycles per second (also known as cps, Hertz.). The carrier signal that the modem modulates must fit within this bandwidth, to exceed the capacity of this frequency "window" we resort to another type of modulation, PHASE encoding. Going beyond representing 1 and 0 with two different frequencies, we now switch between multiple states of phase (for 2400 baud there are 16 states of phase, the current Bell 212a standard uses 4 states of phase) and divide our information within each state. In V.22bis things like "Quadbits" (four consecutive bits) come into play. The first two bits in a quadbit define the change of quadrant (0, 90, 180, 270 degrees of phase) relative to the quadrant occupied by the preceding signal element. The last two bits of the quadbit define one of 4 signalling elements related to the new quadrant.

Here is a chart of common baud rates and their appropriate carrier states :

Bit Rate (bps) Baud Rate Carrier States

300 300 2

1200 600 4

2400 600 16

4800 1200 16

9600 2400 32

Notice how none of the baud rates exceeds the frequency bandwidth limit. Remember that this is for FULL DUPLEX transmission. There is a "High" and "Low" channel for simultaneous transmission and reception. Each channel operating at HALF the overall speed of the unit. At baud rates above 2400 line equalization is necessary to combat the poor quality of phone lines. The next step beyond V.22bis will be V.32.

V.32 will allow full duplex asynchronous transmissions of up to 9600 baud. Telebit of Cupertino (where else ?) is entering into an agreement with a number of heavy telecommunications companies to market their new 10K-baud modem called the "FastLink" (you'll probably see this under the "IRMA" label first). While it is not presently V.32 compatible, they intend to submit what they feel is a superior standard to the CCITT and see if they can have their method adopted in lieu of the current V.32 (V.32 "bis" maybe ?). Concord Data Systems of Waltham, Mass. (among others) intends to release a V.32 standard modem by the end of the year. Both the CDS and the Telebit technologies fall into the $2,000 per modem bracket. For a LOT of corporations, these technologies will pay for themsleves VERY quickly (for FAX transmissions among many other things). And WE are the folks that will inherit this technology as the prices fall. Come on now, admit it ..... wouldn't you just LOVE to have one ??

NOW, onto the protocols that will be necessary to support these high speeds ..... the following two Protocols are in contention. X.PC and MNP. X.PC is being promoted by Tymnet (a major packet switched network) and MNP is being promoted by Microcom (a major modem manufacturer). X.PC is being placed in the public domain and MNP requires a $2,500 licensing fee.

X.PC is a subset of X.25, which is a CCITT standard for packet switched networks such as Tymnet. It is a full duplex asynchronous error correcting protocol that supports up to 15 logical channels. X.PC is a Link Level protocol. The link level is one of the seven levels defined in the ISO / OSI (International Standards Organization Open Systems Interconnect) model. It maintains transparent full time automatic error correction during any communications session between two or more machines (right now this is limited to multiple PC's and/or machines on a Network that supports the X.PC protocol). X.PC protocol (as does MNP) groups bits of data into packets, does a high level statistical analysis of the packets (16 bit CRC) and transmits the results to the receiving end. The X.PC on the receiving end will also perform a statistical analysis of the received packet and if there has been an error in transmission it will request that the originator retransmit the packet. When connected to a Host Network that supports X.PC (such as Tymnet or Telenet) you can execute up to 15 different concurrent sessions (simultaneously talk to 15 different Host Computers) with just one phone link. Each packet of data is encoded with both an address as to which computer system it is destined for and an address as to which system the packet originated from.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All

Fresh From the Land Down Under – The Tou...
After a two week hiatus, we are back with another episode of The TouchArcade Show. Eli is fresh off his trip to Australia, which according to him is very similar to America but more upside down. Also kangaroos all over. Other topics this week... | Read more »
TouchArcade Game of the Week: ‘Dungeon T...
I’m a little conflicted on this week’s pick. Pretty much everyone knows the legend of Dungeon Raid, the match-3 RPG hybrid that took the world by storm way back in 2011. Everyone at the time was obsessed with it, but for whatever reason the... | Read more »
SwitchArcade Round-Up: Reviews Featuring...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for July 19th, 2024. In today’s article, we finish up the week with the unusual appearance of a review. I’ve spent my time with Hot Lap Racing, and I’m ready to give my verdict. After... | Read more »
Draknek Interview: Alan Hazelden on Thin...
Ever since I played my first release from Draknek & Friends years ago, I knew I wanted to sit down with Alan Hazelden and chat about the team, puzzle games, and much more. | Read more »
The Latest ‘Marvel Snap’ OTA Update Buff...
I don’t know about all of you, my fellow Marvel Snap (Free) players, but these days when I see a balance update I find myself clenching my… teeth and bracing for the impact to my decks. They’ve been pretty spicy of late, after all. How will the... | Read more »
‘Honkai Star Rail’ Version 2.4 “Finest D...
HoYoverse just announced the Honkai Star Rail (Free) version 2.4 “Finest Duel Under the Pristine Blue" update alongside a surprising collaboration. Honkai Star Rail 2.4 follows the 2.3 “Farewell, Penacony" update. Read about that here. | Read more »
‘Vampire Survivors+’ on Apple Arcade Wil...
Earlier this month, Apple revealed that poncle’s excellent Vampire Survivors+ () would be heading to Apple Arcade as a new App Store Great. I reached out to poncle to check in on the DLC for Vampire Survivors+ because only the first two DLCs were... | Read more »
Homerun Clash 2: Legends Derby opens for...
Since launching in 2018, Homerun Clash has performed admirably for HAEGIN, racking up 12 million players all eager to prove they could be the next baseball champions. Well, the title will soon be up for grabs again, as Homerun Clash 2: Legends... | Read more »
‘Neverness to Everness’ Is a Free To Pla...
Perfect World Games and Hotta Studio (Tower of Fantasy) announced a new free to play open world RPG in the form of Neverness to Everness a few days ago (via Gematsu). Neverness to Everness has an urban setting, and the two reveal trailers for it... | Read more »
Meditative Puzzler ‘Ouros’ Coming to iOS...
Ouros is a mediative puzzle game from developer Michael Kamm that launched on PC just a couple of months back, and today it has been revealed that the title is now heading to iOS and Android devices next month. Which is good news I say because this... | Read more »

Price Scanner via MacPrices.net

Amazon is still selling 16-inch MacBook Pros...
Prime Day in July is over, but Amazon is still selling 16-inch Apple MacBook Pros for $500-$600 off MSRP. Shipping is free. These are the lowest prices available this weekend for new 16″ Apple... Read more
Walmart continues to sell clearance 13-inch M...
Walmart continues to offer clearance, but new, Apple 13″ M1 MacBook Airs (8GB RAM, 256GB SSD) online for $699, $300 off original MSRP, in Space Gray, Silver, and Gold colors. These are new MacBooks... Read more
Apple is offering steep discounts, up to $600...
Apple has standard-configuration 16″ M3 Max MacBook Pros available, Certified Refurbished, starting at $2969 and ranging up to $600 off MSRP. Each model features a new outer case, shipping is free,... Read more
Save up to $480 with these 14-inch M3 Pro/M3...
Apple has 14″ M3 Pro and M3 Max MacBook Pros in stock today and available, Certified Refurbished, starting at $1699 and ranging up to $480 off MSRP. Each model features a new outer case, shipping is... Read more
Amazon has clearance 9th-generation WiFi iPad...
Amazon has Apple’s 9th generation 10.2″ WiFi iPads on sale for $80-$100 off MSRP, starting only $249. Their prices are the lowest available for new iPads anywhere: – 10″ 64GB WiFi iPad (Space Gray or... Read more
Apple is offering a $50 discount on 2nd-gener...
Apple has Certified Refurbished White and Midnight HomePods available for $249, Certified Refurbished. That’s $50 off MSRP and the lowest price currently available for a full-size Apple HomePod today... Read more
The latest MacBook Pro sale at Amazon: 16-inc...
Amazon is offering instant discounts on 16″ M3 Pro and 16″ M3 Max MacBook Pros ranging up to $400 off MSRP as part of their early July 4th sale. Shipping is free. These are the lowest prices... Read more
14-inch M3 Pro MacBook Pros with 36GB of RAM...
B&H Photo has 14″ M3 Pro MacBook Pros with 36GB of RAM and 512GB or 1TB SSDs in stock today and on sale for $200 off Apple’s MSRP, each including free 1-2 day shipping: – 14″ M3 Pro MacBook Pro (... Read more
14-inch M3 MacBook Pros with 16GB of RAM on s...
B&H Photo has 14″ M3 MacBook Pros with 16GB of RAM and 512GB or 1TB SSDs in stock today and on sale for $150-$200 off Apple’s MSRP, each including free 1-2 day shipping: – 14″ M3 MacBook Pro (... Read more
Amazon is offering $170-$200 discounts on new...
Amazon is offering a $170-$200 discount on every configuration and color of Apple’s M3-powered 15″ MacBook Airs. Prices start at $1129 for models with 8GB of RAM and 256GB of storage: – 15″ M3... Read more

Jobs Board

*Apple* Systems Engineer - Chenega Corporati...
…LLC,** a **Chenega Professional Services** ' company, is looking for a ** Apple Systems Engineer** to support the Information Technology Operations and Maintenance Read more
Solutions Engineer - *Apple* - SHI (United...
**Job Summary** An Apple Solution Engineer's primary role is tosupport SHI customers in their efforts to select, deploy, and manage Apple operating systems and Read more
*Apple* / Mac Administrator - JAMF Pro - Ame...
Amentum is seeking an ** Apple / Mac Administrator - JAMF Pro** to provide support with the Apple Ecosystem to include hardware and software to join our team and Read more
Operations Associate - *Apple* Blossom Mall...
Operations Associate - Apple Blossom Mall Location:Winchester, VA, United States (https://jobs.jcp.com/jobs/location/191170/winchester-va-united-states) - Apple Read more
Cashier - *Apple* Blossom Mall - JCPenney (...
Cashier - Apple Blossom Mall Location:Winchester, VA, United States (https://jobs.jcp.com/jobs/location/191170/winchester-va-united-states) - Apple Blossom Mall Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.