File and Printer Sharing

Overview

One of the key functions provided in the Microsoft Windows Server 2003 family is the ability to share files and printers. The Windows Server 2003 family provides both the Common Internet File System (CIFS), based on the Server Message Block (SMB) file and printer sharing protocol, and the Internet Printing Protocol (IPP), which allows clients to install printer drivers over their intranet or the Internet, as well as to send print jobs using IPP encapsulated in Hypertext Transfer Protocol version 1.1 (HTTP/1.1).

CIFS is an operating-system-independent protocol that evolved from the SMB and NetBIOS file- and printer-sharing mechanisms of earlier versions of Windows. The SMB protocol was created in the 1980s by IBM and later enhanced and extended by IBM, 3Com, Intel, and Microsoft. SMB is now also known by the name CIFS.

CIFS allows clients to access files and printers over their corporate LAN as well as over the Internet. Microsoft and several other vendors are jointly developing CIFS specifications, and a specification draft was submitted to the Internet Engineering Task Force (IETF) in expectation that it might be adopted as an informational RFC (this Internet draft has now expired). Copies of the early drafts of this material are contained in the Cifs folder on the companion CD-ROM.

One problem with CIFS is that there is no up-to-date formally published specification. The draft RFC documents contained in the folder were written in 1997 and have not been significantly updated since. They are largely accurate, although they are not completeand appear inaccurate in some areas. There is an active CIFS mailing list; see http://discuss.microsoft.com/archives/cifs.html for the list's archive and for instructions on how to join the list.

IPP is a method of performing printing operations across a network based on usingHTTP/1.1. With Windows Server 2003, IPP also requires the IPP server to be running Microsoft Internet Information Services (IIS) 6, which is not installed by default.

Introduction to CIFS

CIFS is a cross-platform mechanism allowing clients to request file and print services from a network server based on the widely used SMB protocol.

The SMB protocol was invented by Dr. Barry Feigenbaum of IBM's Boca Raton lab during the early Microsoft Disk Operating System (MS-DOS) days. It was extended by 3Com, IBM, Intel, and Microsoft during the mid- to late 1980s. During late 1996, Microsoftrelaunched the Microsoft Windows NT 4.0 extensions of the SMB protocol as CIFS andreleased a draft RFC. Some of the enhancements that were most visible were the addition of Andrew File System/Distributed File System (AFS/DFS), or Transarc, style referrals and the use of port 445 (to avoid reliance on the RFC 1001 NetBIOS service). To ensure compatibility between older and newer systems, the client and server negotiate which variant of the SMB protocol to use, the highest version that both client and server support.

The version of CIFS included with Windows Server 2003 remains backward-compatible with previous versions of Windows. CIFS is an open protocol, which means that all aspects of communication are publicly documented, although the documentation that is publicly available is incorrect and lacking in places.

The chief advantage that CIFS provides over file access protocols such as HTTP and File Transfer Protocol (FTP) is that it allows simultaneous read and write access to a file, as opposed to the simple file transfer capabilities provided by HTTP and FTP. CIFS supports distributed, replicated virtual volumes such as Distributed File System (Dfs), file and record locking, file change notification, read-ahead and write-behind operations, and most of the functionality typically associated only with direct connections to a corporate network. CIFS functions over any IP-based network, including the Internet.

The SMB protocol was originally based on NetBIOS as a transport protocol, running on top of TCP/IP, IPX/SPX, or NetBEUI. Using TCP/IP, a CIFS client wanting access to a file or print server would first create a TCP connection to the server (assuming that both client and server shared a compatible transport connection). Next, the client would establish a NetBIOS session over the previous transport session. The client would finally use the NetBIOS session to create and then utilize a file and print sharing session with the server. When TCP/IP is used as the transport protocol for the NetBIOS session, the client initiates the NetBIOS session over TCP, using server port 139.

With Windows Server, the file server can directly host the file and print sharing and does not require NetBIOS. A client opening a direct host connection sets up a TCP session using TCP port 445.

File and print sharing sessions can also be established and used with NetBIOS running over IPX/SPX and NetBEUI. However, details of such sessions are outside the scope of this book, which concentrates only on the use of TCP/IP.

CIFS Operation

The steps involved in CIFS file sharing can be summarized as follows:

1. The client determines the IP address of the server and makes a connection to either TCP port 445 or TCP port 139 (if NetBIOS is being used) on the server.
2. If the client is using NetBIOS, then a NetBIOS session is set up over the existing TCP connection.
3. The client then negotiates the SMB dialect to use. The server chooses the most functional dialect that both client and server understand and returns a list of capabilities to the client.
4. The client then requests a session with the server, providing some securityinformation. The exchanges relating to security will be dependent on thespecific security mechanisms in use. If the session can be created, the server responds with the User ID (UID).
5. The client attaches to a share using the UID. The server responds with the Tree ID (TID) relating to that share.
6. The client opens a file using the TID and UID. The server responds with a File ID (FID) to identify the open file.
7. The client then uses the UID, TID, and FID to perform file operations onthe file.
8. When complete, the client closes the file, closes the session, and finally closes the TCP connection, which terminates the file sharing session. If the connection has been made using NetBIOS, closing the underlying TCP connection also closes the NetBIOS session.

These steps are shown in Figure 19-1 and discussed in more detail in the following pages.

Figure 19-1: CIFS file sharing.

Name Resolution and Connection Establishment

The CIFS server registers its name with a name resolution service, using either a fully qualified domain name and the Domain Name System (DNS) or a NetBIOS name and Windows Internet Naming Service (WINS). A client wishing to connect to the CIFS server can query a DNS or WINS server to obtain the IP address of the CIFS server. Capture 19-01, included in the Captures folder on the companion CD-ROM, demonstrates the CIFS protocol. This is a trace of a client, Kapoho11, accessing a file on a share contained on the server Kapoho10.

The first step made by the client is to resolve the name to the IP address of the CIFS server. The client establishes a connection to the CIFS server using TCP port 445 (assuming direct hosting is used). If a NetBIOS-based connection is being used, the client next sets up a NetBIOS session. In the trace, NetBIOS hosting is used.

Once the basic connection is established, the CIFS client negotiates which variant of the SMB protocol is to be used. Clients and servers can understand multiple variants of the SMB protocol and need to negotiate which specific variant to use for this connection.The client performs this by issuing an SMB SESSION REQUEST message over TCP port 139 (the NetBIOS session service) or over TCP port 445 (direct hosting).

The client begins the session negotiation by sending a NEGOTIATE packet to the server. This packet contains a list of the dialects the client is able to use. Table 19-1 lists the full set of SMB dialects, with those understood by Windows Server 2003 noted.

Table 19-1: SMB Dialects

Dialect Name	Comment
PC NETWORK PROGRAM 1.0	The original MSNET SMB protocol (sometimes referred to as a"core protocol").
PCLAN1.0	Some versions of the original MSNET defined this as analternate to the core protocol name (not supported byWindows Server 2003).
MICROSOFT NETWORKS 1.03	This is used for the MS-NET 1.03 product. It defines Lock & Read, Write & Unlock, and a special version of raw read and raw write (not supported by Windows Server 2003).
MICROSOFT NETWORKS 3.0	This is the DOS LANMAN 1.0 specific protocol. It is equivalent to the LANMAN 1.0 protocol, except the server is required to map errors from the OS/2 error to an appropriate DOS error (this dialect is not supported by Windows Server 2003).
LANMAN1.0	This is the first version of the full LANMAN 1.0 protocol.
LM1.2X002	This is the first version of the full LANMAN 2.0 protocol (this dialect is not supported by Windows Server 2003).
DOS LM1.2X002	This is the DOS equivalent of the LM1.2X002 protocol. It is identical to the LM1.2X002 protocol, but the server will perform error mapping to appropriate DOS errors (this dialect is not supported by Windows Server 2003).
DOS LANMAN2.1	DOS LANMAN2.1 (this dialect is not supported byWindows Server 2003).
LANMAN2.1	OS/2 LANMAN2.1 (this dialect is not supported byWindows Server 2003).
Windows for Workgroups 3.1a	Windows for Workgroups Version 1.
NT LM 0.12	This is the latest version of the SMB protocol designed for Windows NT networking. This has special SMBs that duplicate Windows NT, Windows 2000, and Windows Server 2003 file handling semantics.

Windows Server 2003 clients and servers attempt to negotiate NT LM 0.12, which allows the server to issue parameters that specify things such as encryption key lengths, maximum message sizes, and whether the server is Dfs aware.

The server responds to the client with a NEGOTIATE packet identifying the highest dialect that both machines understand, as well as parameters specific to that dialect. Table 19-2 describes the components of a CIFS server NEGOTIATE response.

Table 19-2: Components of a CIFS Server NEGOTIATE Response

Server Response	Description
WordCount	A count of the parameter words in the packet (17 in the case of NT LM 0.12 dialect).
DialectIndex	The index of the selected dialect. For example, if the client offered six dialects, numbered 0–5, with 5 representing NT LM 0.12, the index would be 5.
SecurityMode	Security Mode of the selected dialect consists of 4 bits, as follows: Bit 0 Set to 0 to indicate share-level security or set to 1 to indicate user-level security. Bit 1 If set to 1 this indicates that passwords must be encrypted. Bit 2 Set to 1 to indicate that SMB signatures are enabled. Bit 3 Set to 1 to indicate that SMB signatures are required.
MaxMpxCount	Maximum number of pending multiplexed requests (default is 50).
MaxNumberVcs	Maximum number of virtual circuits between client and server (the default is 1).
MaxBufferSize	This is the size of the largest message that the client can transmit to the server. The default value is 4356 bytes.
MaxRawSize	Maximum raw-buffer size. This is the maximum message size that the server can send or receive for SMB_COM_WRITE_RAW or SMB_COM_READ_RAW operations. The default is 65,536 bytes.
SessionKey	The unique key identifying this session.
Capabilities	Server capabilities. These parameters are listed in Table 19-3.
SystemTimeLow	System (Universal Time Coordinate [UTC]) time of the server (low).
SystemTimeHigh	System (UTC) time of the server (high).
ServerTimeZone	Time zone of the server (minutes from UTC).
EncryptionKeyLength	Length of the encryption key.
ByteCount	Count of data bytes.
Server Guid	A globally unique identifier (GUID) uniquely identifying the server.
Security BLOB	An opaque security object.

By returning a list of its capabilities, the server informs the client which operations might or might not be performed at the client's request. Table 19-3 lists the bit definitions of the server's capabilities.

Table 19-3: Bit Definitions of Server Capabilities

Capability	Encoding	Description
CAP_RAW_MODE	0x0001	The server supports SMB_COM_READ_RAW and SMB_COM_WRITE_RAW.
CAP_MPX_MODE	0x0002	The server supports SMB_COM_READ_MPX and SMB_COM_WRITE_MPX.
CAP_UNICODE	0x0004	The server supports Unicode strings.
CAP_LARGE_FILES	0x0008	The server supports large files with 64-bit offsets.
CAP_NT_SMBS	0x0010	The server supports the SMBs particular to the NT LM 0.12 dialect.
CAP_RPC_REMOTE_APIS	0x0020	The server supports remote application program- ming interface (API) requests using remote procedure calls (RPCs).
CAP_STATUS32	0x0040	The server can respond with 32-bit status codes.
CAP_LEVEL_II_OPLOCKS	0x0080	The server supports level 2 oplocks.
CAP_LOCK_AND_READ	0x0100	The server supports the SMB_COM_LOCK_AND_READ SMB.
CAP_NT_FIND	0x0200	The server supports NT Find.
CAP_DFS	0x1000	The server is Dfs-aware.
CAP_LARGE_READX	0x4000	The server supports SMB_COM_READ_ANDX requests that exceed the negotiated buffer size.

Once the CIFS client receives a NEGOTIATE PROTOCOL response, it completes the session negotiation by issuing a SESSION SETUP ANDX SMB to the server. Table 19-4 describes the components of a SESSION SETUP ANDX SMB.

Table 19-4: Components of a SESSION SETUP ANDX SMB

Client Request	Description
Word Count	A count of the parameter words in the packet (17 in the case of NT LM 0.12 dialect)
AndXCommand	Secondary (X) command; set to 0xFF = none
Reserved	Two octets, set to 0x0000
AndXOffset	Offset to next command WordCount
Max Buffer	Maximum buffer at the client
Max MPX Count	Actual maximum multiplexed pending requests
VC Number	0 = first (only), nonzero = additional VC number
Session Key	Session key
Security Blob Length	Length of opaque security blob
Reserved	Four octets set to 0x000000
Capabilities	Client capabilities
ByteCount	Count of data bytes; minimum = 0
SecurityBlob	The opaque security blob
NativeOS	Client's native operating system in Unicode
NativeLanMan	Client's native LAN Manager type in Unicode

The CIFS server then responds with a SESSION SETUP ANDX response message. This message contains a UID to the client session. Additional sessions can be set up over the same connection without prompting the user for a password. CIFS can use any authentication supported by client and server, including Windows 2000 or Windows Server 2003 Kerberos authentication mechanisms.

The connection between client and server in an SMB session is called a virtual circuit (VC), which is formed over the transport service, typically TCP. Within a VC, the server assigns a TID that provides a unique identifier for each file sharing session and defines the types of access allowed over that connection. A process ID (PID) identifies the process environment for that session, and an FID is assigned to each file opened during the session. If a VC is closed, all environments within the VC (TID, PID, FID) are also closed. However, the closing of a single FID might not result in the closing of the VC, as multiple operations can be requested over a single VC.

Session Operations

Once a session has been established, a client can request four basic sets of operations against the file server:

• File management requestsThe client can request the server to create (or open), read from, write to, and lock and close a file or create a temporary file. The client can delete, rename, move, or copy a file. In addition, clients can query and set both file and path information.
• Directory management requestsClients can create, delete, and searchdirectory entries.
• Dfs operationsClients can request a Dfs referral from a Dfs server to atarget server.
• Miscellaneous operationsClients can request device and file system control functions to be transferred transparently to the server, as well as query and set the security descriptor on a file or directory.

Session Disconnection

When a client wishes to disconnect its session to a CIFS server, it follows a teardown process that is essentially the reverse of the session-establishment process. Any open files are closed and their associated FIDs and PIDs then can be disconnected. The TID is disconnected and the user logs off, which results in the server discarding that client's UID. If the client should reconnect, the user is again prompted for credentials because the UID assigned during the last session no longer exists.

Connection Management

CIFS provides mechanisms that allow for efficient disconnections when a client and server have completed all session traffic or when a connection is lost or malfunctioning. A client can issue a connection request only once to a CIFS server in any given session. If the CIFS server receives another connection request from a client with whom it already has an established session, the server disconnects the original session with the client to help ensure that a client that was unexpectedly disconnected from its session can effectively establish another session with the server. If a client is generating malformed or illegal requests to the CIFS server, the server can issue an error to the client and then disconnect the session, again potentially allowing the client to correct the problem and reconnect. A server can also disconnect a session with a client in the case of hard transport errors or if the client has been inactive for a long period of time and the server needs the connection.

File and Printer Access

After a client has established an SMB session with a CIFS server, the client can begin requesting files by issuing open SMBs to the server for the files it wishes to access. A file can be opened for read access, write access, or both. Accessing a printer is accomplished using a read request to the printer. Printing is accomplished using a write request to the printer.

Distributed File System Operations

Any client and CIFS server that supports dialects NT LM 0.12 and later supports Dfs operations. Using Dfs, the CIFS server can represent multiple shares on multiple servers in a single namespace that appears to the client to be located on a single server. The CIFS server can redirect the client software to another location on the network to access a resource, but the client will believe the resource is local to the server with which it originally negotiated a connection.

When a client wants to access a file that is contained in a Dfs share, it will issue a normal set of SMBs, because the client is not initially aware that part of a file path represents a Dfs share. The client sets a flag in the request SMB header indicating that the client wants the server to resolve this SMB's paths within the Dfs known to the server. The server then attempts to resolve the requested name to a file contained within the local directory tree indicated by the TID of the request. If this succeeds, then processing proceeds normally. If, however, the request path name resolves to a file on a different system, the server returns the error STATUS_DFS_PATH_NOT_COVERED. This indicates that the server does not support the part of the Dfs namespace needed to resolve the path name in the request. The client should request a referral from this server for further information.

The client can then ask for a referral using the TRANS2_DFS_GET_REFERRAL request containing the Dfs path name of interest. The response from the server indicates the server and share that the Dfs client should now attempt to access.

Read-Ahead and Write-Behind

To improve performance, CIFS supports read-ahead and write-behind operations. Read-ahead allows a client to cache read data locally so that it does not have to incur traffic over its connection to the server to obtain the next block of data it wants to read. Write-behind allows a client to perform and cache write operations on a file that then can be uploaded to the server, rather than having to submit each read/write operation separately.

Files on the server can also be called locked or unlocked. An unlocked file is a file to which no client has been granted exclusive access for either read or write purposes. CIFS supports caching, read-ahead, and write-behind, even for unlocked files, because the files are said to be "safe" as long as no client is actively writing to the file. If a client wants to write to a file, it must either submit the write data to the server for the server to write, or it can request a lock from the server.

Opportunistic Locks

When a client is actively writing to a file on the server, it can be more efficient for the client to locally buffer its data and submit it as a batched request. However, this increases the possibility that the same file might be opened by another client and data might also be written by that client. To help a client increase the efficiency of its data buffering, CIFS allows for opportunistic locks (referred to as oplocks), which allow the client to "lock" the file, or part of a file, so that it can't be written to simultaneously by another client. The following are three types of oplocks used in CIFS:

• Exclusive oplocksIn an exclusive oplock, a client (Client A) requests exclusive access to a file, where Client A is the only client permitted to write data to the file. When Client A opens the file, it requests an exclusive oplock from the server. If another client (Client B) has already opened the file, the server refuses to issue the oplock to the requesting client (Client A). When this occurs, Client A is does not buffer any data and does not perform any read-ahead. If there are no other clients currently accessing the file, the exclusive oplock will be granted to Client A and it can both read-ahead and buffer data that is to be written to the file. If Client C opens the file while Client A has an exclusive oplock, the server instructs Client A to break its lock. Breaking the lock requires Client A to submit any buffered lock or write data it's currently holding, acknowledge receipt of the notification, and purge its read-ahead buffer so that the file can be released for access by Client C.
• Level II oplocksLevel II oplocks allow multiple clients to open the same file, provided that no client is writing to that file. In a level II oplock, Client A can open a file and request an exclusive oplock to it. If it is the only clientaccessing the file, the server grants the oplock. When Client B requests access to the same file, the server contacts Client A and requests that it break its lock to a level II oplock if Client A hasn't been writing to the file. This is a result of the fact that some down-level client applications request read/write access to files even when they don't intend to perform write operations. After the server has synchronized with Client A to ensure that Client A has no locked buffer data, access to the file is granted to Client B at a level II oplock status. Thisinforms Client B that it can't buffer any locks to the file, although it has been granted access. Either client can eventually write to the file; should this occur, the server notifies all level II oplock clients to break their locks, thus allowing the data to be written by a single client and ensuring that the server does not have to synchronize with all connected clients to allow this.
• Batch oplocksBatch oplocks are commonly used by applications that run command batches requiring them to repeatedly open and close multiple files to read and execute their command sequences. When Client A wants to obtain a batch oplock to server files, it requests the oplock from the server. If other clients do not have the files open, the batch oplock is granted. Client A can now open the files, leave them open while executing its command sequences, and buffer data as needed. If Client B requests access to one of the files while Client A has a batch oplock, the server notifies Client A to clean up its data and synchronize with the server. In most cases, this results in Client A finishing its current batch operation and closing the file in question, allowing Client B to open the file.

Introduction to Internet Printing

Internet printing in the Windows Server 2003 family allows you to install, use, and monitor a printer over an internet. This can, but probably will not include the Internet and might include using a corporate intranet. Using IPP, you can install a printer using a Web browser or the Add Printer Wizard, but you can specify a Uniform Resource Locator (URL) or IP address instead of a Universal Naming Convention (UNC) path to the printer. When submitting a print request, the user can then use the installed printer interface to print directly to the URL. The print server must, however, be running IIS to accept these print requests. Because the print server uses the HTTP functionality of IIS, it can return information regarding the print job in browser-ready format. The underlying protocol that allows Internet printing to function is the IPP, which is sent encapsulated in an HTTP/1.1 request to the print server. The implementation of IPP in the Windows Server 2003 family is unchanged, functionally, from IPP in Windows 2000.

IPP Operation

IPP is defined in the following RFCs:

• RFC 2567, Design Goals for an Internet Printing ProtocolThis RFC looks at the features that would be needed in a printing protocol for the Internet.
• RFC 2568, Rationale for the Structure of the Model and Protocol for the Internet Printing ProtocolThis RFC provides a high-level overview to the functions and features of IPP.
• RFC 2911, Internet Printing Protocol/1.1: Model and SemanticsThis RFC describes IPP from a high-level viewpoint.
• RFC 2910, Internet Printing Protocol/1.1: Encoding and TransportThis RFC formally maps IPP onto HTTP/1.1 and defines the encoding rules for a new Internet Multipurpose Internet Mail Extensions (MIME) media type called application/ipp.
• RFC 2569, Mapping between LPD and IPPThis RFC gives some adviceto implementers of gateways between IPP and line printer daemon (LPD) implementations.

IPP presents a very simplified model of printing that can be implemented on top of a variety of architectures. IPP defines two principal objects as the basis for Internet printing: a printer and a job. The printer object is the server-side component of the IPP protocol. In the Windows Server 2003 family, the IPP printer can be any printer that is installed on a computer running IIS. IPP also requires an underlying directory that can be used to store and retrieve definitions of IPP printers. However, the printer object shouldn't be confused with the output device. The output device is the physical device, which can be a simple printer, fax printer, or software, such as desktop publishing programs, document archive software, or a CD writer. The physical output device does not need to be IPP-aware or IPP-compliant as long as the printer object (the IPP server) handles the IPP.

With the Windows Server 2003 family, a user can query the Active Directory service to locate a printer object based on a printer's attributes, such as its location or capabilities. When a user sends a document for printing using IPP, the client computer submits the document as a print job, which contains a listing of the document's print attributes. The print submission is sent to the printer object, which validates the submission's attributes and creates a new job object. The newly created job object can then be queried. This facilitates reporting on print status and errors.

An IPP client is a computer running an HTTP/1.1-compatible browser, such as Microsoft Internet Explorer, and an installed printer software interface representing the print object. The user at the client computer installs the printer by entering its URL or IP address in either a Web browser or the Add Printer Wizard. After the printer has been added on the client computer, the user can submit print jobs from any application as if the printer were a network printer. When you try to print from a Windows Server 2003 client, theclient attempts to use normal SMB print sharing before using IPP.

When you are printing, the client IPP software processes the print job in the appropriate format for the printer object. The IPP client then submits the job as an encapsulated HTTP/1.1 request to the printer object, which might be a print server or the actual output device. RFC 2566 specifies three different scenarios for setup of the printer objects and output devices. Figures 19-2, 19-3, and 19-4 diagram each of these scenarios.

Hosted Printing

In hosted printing, the IPP client sends a print job to the printer object, which is represented in Active Directory. The client locates the printer object by querying Active Directory for printers that are capable of specific functionality. However, queries for dynamic information, such as job status and queue length, are submitted to the printer object itself. The printer object in this scenario, as shown in Figure 19-2, is a print server running the IPP service (IIS, for example). The output device is a physical print device or software application that can be installed directly on the print server network. The output device does not need to support any IPP functionality, because the printer object, in this case the IIS server, performs all processing related to IPP and sends the job to the output device as it would any locally submitted print job. The printer object is also responsible for providing status monitoring and notification functionality to the requesting client using HTTP/1.1, which is why the server must be running IIS to serve as an IPP printer object.

Figure 19-2: IPP hosted printing.

Fan Out Printing

Fan out printing is very similar to hosted printing, except that the print object can transparently direct the print job to any of a number of physical output devices (as shown in Figure 19-3). These devices can be physical print devices, fax printers, or software on the local computer or another computer on the network. As with hosted printing, the output device does not need to use IPP, because the IPP server or printer object handles that functionality. Client queries relating to job status are submitted to the printer object, not to the output devices.

Figure 19-3: IPP fan out printing.

Embedded Printing

In embedded printing, the printer object and the output device are the same entity, and might or might not be represented in Active Directory. Unlike hosted and fan out printing, there is no intermediary server acting as the print object and print server for the output device (as shown in Figure 19-4). Embedded printing requires that the output device be capable of receiving and processing IPP client requests, as well as returning information to the client over HTTP. Therefore, this implementation requires additional functionality on the part of the output device, which is already provided by some printer vendors.

Figure 19-4: IPP embedded printing.

IPP Specifications

IPP structure and semantics are defined in a series of RFCs, as noted earlier in this chapter. The IPP specifications define two layers to the protocol: transport and operation. The transport layer of the protocol consists of HTTP/1.1 requests and responses, defined in Chapter 21, "Internet Information Services (IIS) and the Internet Protocols." The operation layer is a message body embedded in the HTTP/1.1 requests and responses. Each request or response message contains a sequence of attributes that describe the capabilities and characteristics of the objects involved in the printing operation. These object attributes are as follows:

• Printer attributesPrinter object attributes fall into two categories: printer description attributes and printer job template attributes. Printer descriptionattributes are those that define properties, such as the printer object's location and state. Printer job template attributes describe the printer object's capabilities, such as the types of jobs it can handle and its default settings.
• Job attributesJob attributes are properties of a print job that has been processed by the printer object and assigned to a job object. Job attributes can come from job template attributes, or attributes that the client submits to override default printer job template attributes. For example, a printer object can, by default, assign a specific priority to a print job. However, for a particular job, the client might need to override these defaults. Job attributes can also be job description attributes, which provide parameters, such as the job's size, state, and identification. Clients provide some job description attributes when they request the print job, and other attributes are provided by the print object as it processes the print request. For example, a requesting client can provide information regarding the number of pages in a print request (client-side job descriptionattributes), and the printer object can assign a job a Uniform Resource Identifier (URI) when it accepts the job for printing (server-side job description attributes).
• Operation attributesUnlike printer object and job object attributes, which provide characteristics relating to the objects involved in a print transaction, operation attributes describe the transaction itself. These attributes identify properties, such as where the job is being sent and what localization parameters might need to be defined in the transaction.
• Unsupported attributesBecause IPP attributes are extensible, a client from a particular vendor can issue a request containing attributes that are only supported by the print object provided by the same vendor. If the same attributes are sent to an IPP of another vendor, then these attributes might not be supported. If this is the case, the IPP server returns a message to the client listing which attributes it does not support. This enables the IPP client to issue only those requests that the print object can fulfill. This process allows the client and server to "negotiate" job parameters during the request and response sequences.

  More Info

  IPP structure and semantics are defined primarily in RFCs 2565 and 2566, which can be found in the Rfc folder on the companion CD-ROM.

IPP Request Response Mechanisms

IPP operations are passed between client and server as a series of HTTP/1.1 request and response messages. When a client submits a print request to a print object (IPP server), the client sends a request message to the printer object URI. This message contains operation attributes, object attributes, and the document to be printed. Each request message is followed by a response message from the IPP server. The response message contains a code indicating the success or failure of the requested operation, as well as operation attributes, object attributes, and status messages that the server generated.

After the server has accepted the print request and created a job object with its own URI, the client can request the addition of further documents to the same job object. Although a printer is not required to support job objects that contain more than one document, allowing the submission of multiple documents to a single job object increases printing efficiency and allows print requests to be "batched." Because each job object can be queried, the client can use a single job URI to obtain status reports on multiple documents if the server supports this mechanism.

Each operation request issued by the IPP client must contain a Version-Number, an Operation-ID, a Request-ID, and any attributes required by the specific request type. Each server response message must contain a Version-Number, a Status-Code, the Request-ID that the client issued, and any attributes that are specific to that request type. Figure 19-5 illustrates the format for these requests and responses.

Figure 19-5: Request/Response format.

As Figure 19-5 demonstrates, the Version-Number is the version identifier for the request/response sequence. The Operation-ID is used in a request message to specify what operation the client wants to request of the print object, and the Status-ID is sent in the server's response message to indicate whether that operation was successfully received and processed. The Request-ID is used to assign a number to the request for tracking purposes. The 1-byte Attributes field identifies the type of attributes being sent in this request or response message (printer, job, operation, or unsupported), and the variable-length Attributes sequence lists the attributes particular to that type. The end of theAttributes sequence is indicated by a 1-byte End-Of-Attributes tag, and the remaining bytes might or might not consist of the actual print data being sent.

Operations

An IPP client requests submission of a print job by sending an HTTP Request message containing an operation request and attributes to the printer's URI. The printer uses the information provided by the client to construct a new job object, the URI of which is then passed back to the client so that the client can use it for purposes of querying or adding to the job. IPP version 1 defines certain operations, listed in Table 19-5, which can be requested of a printer or a job.

Table 19-5: IPP Operations

Operation	Type (Printer or Job)	Description
Print-Job	Printer	Required. Allows a client to submit a print job and supply the document data, which is not considered a separate rate object and therefore has no attributes of its own. Includes the operation attributes, character set and natural language attributes, and printer URI.
Print-URI	Printer	Identical to a Print-Job operation except that the client supplies a job URI reference to the print data as opposed to submitting the data itself. The printer then validates the job URI before responding to the client.
Validate-Job	Printer	Required. Similar to a Print-Job operation except that no data is supplied in the request/response process. The client uses it to verify that a print job submitted to this printer would be accepted and processed.
Create-Job	Printer	Similar to Print-Job, except that the client sends no document data in the operation, but issues attributes for multiple print requests to submit them to a single job object.
Get-Printer-Attributes	Printer	Required. Allows the client to request printer attributes to determine the capabilities of the printer.
Get-Jobs	Printer	Required. Allows the client to request a list of job objects owned by the printer object.
Send-Document	Job	Allows the client to send a multidocument job object request, so that multiple requests can be submitted under a single job.
Send-URI	Job	Identical to the Send-Document operation, except that the client supplies a document URI operation attribute rather than the document data itself.
Cancel-Job	Job	Required. Allows a client to request cancellation of a print job.
Get-Job	Job	Required. Allows a client to request the attributes of the Attributes job object identified in the message.

Each of these operations can be sent as part of either a request or response message between IPP client and printer. Each operation includes attributes that identify the details of the request or response. Printer attributes can be sent as part of a printer operation message, and job object attributes can be sent as part of a job operation.

Attributes

Attributes are extensible characteristics or properties of any object in IPP, such as printer objects, job objects, and operations. Attribute specifications include the name of theattribute, followed by its syntax in parentheses. Tables 19-6, 19-7, 19-8, and 19-9 describe these attributes.

Table 19-6: IPP Operation Attributes

Attribute	Description
Attributes-charset	Required. Must be supplied as the first attribute in any request or response to define the character set that the client or the IPP server uses.
Attributes-natural-language	Required. Must be supplied as the second attribute in any request or response message to define the natural language that the client or IPP server uses.

Table 19-7: IPP Job Template Attributes

Attribute	Description
Job-priority (integer (1:100))	Priority for job scheduling; 1 is the lowest priority and100 is the highest.
Job-hold-until (type3 keyword | name (MAX))	Named time frame during which the job must become eligible for printing; values include the following: no-hold(immediately); day-time (during the day); evening(evening); night (night); weekend (weekend); second- shift (after close of business); third-shift (after midnight); and indefinite.
Job-sheets (type3 keyword | name (MAX))	Job start/end sheets that must be printed with the job (if any). Keyword values: none (no job sheet printed); standard (site-specific standard sheets are printed, administrator-defined values).
Multiple-document handling (type2 keyword)	If a job consists of more than one document, this controls the placement of pages onto media sheets (such as large sheets of paper used in commercial printing). Keywords: single-document (multiple documents must be treated as a single media sheet); separate-documents-uncollated- copies (each document is treated as a single, noncollated media sheet); separate-documents-collated-copies (each document is treated as a single media sheet and the media sheets are collated); single-document-new-sheet(each document instance in the job must be forced onto a new sheet).
Copies (integer (1:MAX))	Number of copies to be printed, ranging from 1 through the maximum number supported by the output device(such as number of collation trays for collated copies, or the maximum number of noncollated copies allowed by the output device).
Finishings (1setOf type2 enum)	Identifies the finishing operations used for each copy of each document in the job. Enum values: 3 = no finishing; 4 = staple; 5 = punch; 6 = cover (used to specify a cover sheet); 7 = bind (specifies site-defined binding operations).
Page-ranges (1setOf	Range of pages to be printed for a document. A page rangerangeOfInteger (1:MAX)) of 1:5, 24:24 would specify pages 1–5 and page 24 should be printed.
Page-ranges-supported (Boolean)	Indicates whether the printer supports printing of ranges(0 = No, 1 = Yes).
Sides (type2 keyword)	Specifies whether printing is one-sided or two-sided. Keyword values: one-sided; two-sided-long-edge; duplex or head-to-head; two-sided-short-edge.
Number-up (integer (1:MAX))	Number of pages to place on a single side of the selected medium.
Orientation-requested	Page orientation, such as portrait, landscape, reverse (type2 enum) landscape, or reverse portrait (used in commercial printing).
Media (type3	Media type used by the printer, such as paper type,keyword | name (MAX)) paper size, paper tray, or electronic form.
Printer-resolution (resolution)	The resolution used by the printer for the job.
Print-quality (type2 enum)	Print quality used by the printer for the job. Enum values: 3 = draft; 4 = normal; 5 = high.

Table 19-8: IPP Job Description Attributes

Attribute	Description
Job-uri (URI)	Required. The URI for this print job.
Job-id (integer (1:MAX))	Required. Job ID generated by the print object on receipt of a new job and returned to the requesting client for identification purposes.
Job-printer-uri (URI)	Required. Identifies the printer object that created the job object.
Job-more-info (URI)	Contains the URI referencing a resource that has more infor mation about the job object (such as a Hypertext Markup - Language [HTML] page listing job status information).
Job-name (name (MAX))	Required. User-friendly name assigned to the print job. Generated by the print object and returned to the client.
Job-originating-user-name	Required. Name of the user who submitted the print job. (name (MAX)) Can be used for authentication purposes in access-controlled print environments.
Job-state (type1 enum)	Required. Identifies the current job state. Values: 3 = pending; 4 = pending-held; 5 = processing; 6 = processing-stopped; 7 = canceled; 8 = aborted; 9 = completed.
Job-state-reasons	Provides additional information about the job-state attribute,(1setOf type2 keyword) such as none, job-incoming, submission-interrupted, job-outgoing, and so forth.
Job-state-message (text (MAX))	Job-state and job-state-reasons information provided in friendly message format.
Number-of-documents	Indicates the number of documents in the job.(integer (0:MAX))
Output-device-assigned	Identifies the output device to which the printer object (name (127)) assigned the print job. If this is an embedded printer object, this attribute is unnecessary.
Time at creation.(integer (0:MAX))	Time at which the job object was created
Time at processing.(integer (0:MAX))	Time at which the job object began processing
Time at completed(integer (0:MAX))	Time at which the job object was completed, canceled or aborted.
Number-of-intervening jobs.(integer (0:MAX))	The number of jobs "ahead" of this job in the queue
Job message from operator(text (127))	Message sent to the client from an operator or administrator of the printer.
Job-k octets (integer (0:MAX))	Total size in k octets (units of 1024 octets, or kilobytes) of the document.
Job impressions(integer (0:MAX))	Total size of the document in number of impressions (pagesas chosen by the client, such as letter or legal).
Job media sheets.(integer (0:MAX))	Total number of media sheets to be produced for the job
Job k octets processed.(integer (0:MAX))	The total number of k octets processed so far
Job impressions completed(integer (0:MAX))	Number of impressions completed, which includes interpreting, marking, and stacking the output, and both sides of the impression.
Job media sheetscompleted(integer (0:MAX))	The media sheets completed for the job, whether both sidesof the sheet have been processed or not.
Attributes charset (charset)	Required. Identifies the character set used in the job.
Attributes natural language(English,(naturalLanguage)	Required. Identifies the natural language of the job French, and so forth).

Table 19-9: IPP Printer Description Attributes

Attribute	Description
Printer-uri-supported	Required. Contains one or more URIs used to submit print (1setOf uri) jobs to this print object. Multiple URIs allow the print object to be represented as multiple objects in a directory service, but represent a single IPP server.
Uri-security-supported(1setOf type2 keyword)	Required. Identifies the security mechanisms for each of the URIs that identify a printer object (such as none or SSL3).
Printer-name (name (127))	Required. Friendly name of the printer object.
Printer-location (text (127))	Friendly text identifying the location of the printer.
Printer-info (text (127))	Friendly description of the printer.
Printer-more-info (URI)	Specifies a URI where more information about the printer can be obtained, such as an HTML page listing the printer's capabilities.
Printer-driver-installer (URI)	URI used to locate the driver installer for the printer object.
Printer-make-and-model.(text (127))	The make and model of the printer object
Printer-more-info-manufacturer.(URI)	Manufacturer's information about this printer
Printer-state (type1 enum)	Required. Identifies whether the printer is idle, pending, processing, or stopped.
Printer-state-reasons	Provides more information about the reported state of the(1setOf type2 keyword) printer, such as paused or shutdown.
Printer-state-message.(text (MAX))	Friendly message that represents the printer state to the user
Operations-supported(1setOf type2 enum)	Required. Operations that are supported by the printer for itsjob objects.
Charset-configured (charset)	Required. The configured character set of the printer.
Charset-supported(1setOf charset)	Required. A list of character sets supported by the printer.
Natural-language-configured(naturalLanguage)	Required. The configured natural language of the printer.
Generated-natural-language- supported (1setOf printer.naturalLanguage108)	Required. A list of natural languages supported by the
Document-format-default(mimeMediaType)	Required. The default document format that the printer assumes if the client does not specify a particular format.
Document-format-supported(1setOf mimeMediaType)	Required. MIME media types supported by the printer.
Printer-is-accepting-jobs(Boolean)	Required. I ndicates whether the printer is currently accepting job requests.
Queued-job-count(integer (0:MAX))	Recommended. The number of jobs in the print queue for this printer object.
Printer-message-from-operator	Text sent from an administrator or operator to the client.(text (127))
Color-supported (Boolean)	Indicates whether the printer is capable of color printing.
Reference-uri-schemes- supported (1setOf uriScheme)	List of URI schemes that the printer can accept jobs from, such as FTP and HTTP.
Pdl-override-supported of (type2 keyword)	Required. Specifies whether the printer object is capable overriding document defaults as supplied by the application that requested the print job with IPP settings.
Printer up time(integer (1:MAX))	Required. Amount of time, in seconds, that the printer hasbeen up and running.
Printer current time (dateTime)	The current date and time where the printer is located.
Multiple operation time out (integer (1:MAX))	Maximum time, in seconds, that the printer waits for additional instructions on a multidocument job before taking recovery action.
Compression supported (1setOf type3 keyword)	Printer supported HTTP compression types, such as none, gzip, deflate, and compress.
Job k octets supported(rangeOfInteger (0:MAX))	Upper and lower boundaries of k octets that the printer can accept in a single job.
Job impressions supported(rangeOfInteger (0:MAX))	Upper and lower bounds for the number of impressions per job.
Job media sheets supported(rangeOfInteger (0:MAX))	Upper and lower bounds of the number of media sheets supported per job.

Internet Printing Security

Because a printer object can be represented by more than one URI, an administrator has very flexible control options. For example, a printer can be represented by one URI that accepts unsecured HTTP connections and another URI that only accepts Secure Sockets Layer (SSL) connections. The printer administrator can grant specific permissions to each of the URIs, thereby permitting some clients to print over an unsecured connection and forcing others to print only over a secured connection. Additionally, because the printer object can be published in Active Directory, all Windows 2000 security mechanisms can be applied to the printer. Although IPP provides mechanisms for printing using HTTP, it does not provide full file-sharing functionality; CIFS provides that functionality.

Summary

CIFS enables platform-independent file and printing sharing sessions to be established between a client and a server over the Internet or an intranet. CIFS clients use these connections to access file and print resources including Dfs. IPP can extend the functionality and ease of printing in the Windows Server 2003 family. Using IPP, installing and using a printer can be as simple as typing a URL into a Web browser. The IPP functions of IIS also allow you to query individual printers and to view and manage the printer queue using an Internet browser.