 |
Description  |
|
|
FIELD OF INVENTION
This invention relates in general to electronic methods, and in particular,
to a calendaring method in which replies to invitations to participate in
calendar events permit the invitee to designate an alternate.
CROSS-REFERENCES TO RELATED APPLICATIONS
1. Co-pending application Ser. No. 008,034 filed concurrently herewith,
entitled "Method For Concurrently Displaying Entries From a Plurality of
Different Electronic Calendars Based on Interactively Entered Criteria,"
and assigned to the assignee of the present application is directed to an
electronic calendaring method in which a calendar owner can display a set
of calendar entries from different calendars which have an
interrelationship that the user defines by data that is entered into the
system interactively.
2. Co-pending application Ser. No. 008,039 filed concurrently herewith,
entitled "Electronic Calendaring Method to Establish Calendar Floating
Triggers for Calendared Events and Processes" and assigned to the assignee
of this application is directed to an electronic calendaring method in
which a calendar owner can selectively trigger a predefined action and
response to detecting one or more criteria related to the calendar event
that has previously been defined and entered into the system.
3. Co-pending application Ser. No. 008,249 filed concurrently herewith,
entitled "Method For Automatically Reconciling Entries on Two Copies of
Independently Maintained Electronic Calendars," and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner who keeps a detached personal copy of his
master calendar can automatically reconcile the calendar entries that have
been made on each calendar copy, independently of the other since the last
time the detached copy was made and interactively resolve calendar event
conflicts.
4. Co-pending application Ser. No. 008,033 filed concurrently herewith,
entitled "Method For Developing Automatic Replies in an interactive
Electronic Calendaring System," and assigned to the assignee of the
present application is directed to an electronic calendaring method in
which a calendar owner can respond automatically to requests for
participation in events being calendared by another person. The nature of
the reply is based on an analysis of the parameters set forth in the
request and an algorithm employing a set of prioritized criteria that the
calendar owner has established to provide the automatic response.
5. Co-pending application Ser. No. 008,036 filed concurrently herewith,
entitled "Electronic Calendaring Method for Automatic Confirmation of
Resource Availability During Event Calendaring", and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner, when calendaring an event such as a
meeting, which requires, in addition to a meeting room, such articles as a
projector, video conferencing equipment, etc., automatically receives
confirmation that requested articles are available and reserved for the
calendared meeting event.
BACKGROUND ART
The prior art has disclosed a number and variety of interactive electronic
calendaring systems and method. The objective of all of these systems is
primarily to assist the person who, for a number of different reasons,
maintains a calendar of future events containing various information about
the event at entry points on the calendar which relate to the time of the
event.
The increase of personal computers and intelligent workstations in recent
years has made it possible for calendar owners to establish and maintain
their calendars on these interactive type data processing systems.
Two general types of interactive electronic calendaring systems have thus
evolved in the art. In one type of calendaring system, the owner of the
calendar is generally also the user of the workstation and that
workstation is generally not a part of a larger network. Generally, in
these types of systems, the calendar functions involve presenting a screen
to the user representing a day calendar divided into a number of time
periods or time slots. Each period is capable of displaying a limited
amount of text that the user enters. In some systems, the day calendar can
scroll vertically to present more time periods to the user or horizontally
to present longer text entries. The operator can generally "page" forward
or backward and, in most arrangements, can display a requested date. These
calendaring arrangements generally do not limit the type of event that is
calendared nor the terminology employed at any of the entry points and, to
that extent, function in the same manner as conventional manual calendars
or appointment books. The electronic calendaring method and systems do
have an advantage over the prior art manual calendaring of events in that
the user generally has the ability to scan a time span involving a large
number of days and identify calendared events quite rapidly.
The other type of calendaring arrangement that has developed in the prior
art involves multi-user environments having a large number of terminals or
workstations which are generally part of a larger communication network
that has been established to permit the users to interact with each other
and with data maintained on the data processing system. In this
environment, a user at a terminal or workstation can send a message to one
or more of the other users on the network and is notified when the
addresses has received and read the message.
In most of these environments, each user generally maintains a calendar,
and in many of these environments the reason for the interaction with each
other quite often generally involves reference to respective calendars. A
considerable amount of time is therefore spent in many organizations, with
people checking and rearranging their calendars to accommodate various
events such as meetings, presentations, etc. In this environment, the
calendar systems and method have progressed to the point where a person
who is calling a meeting can at least review within the constraints that
the security system dictates, the calendars of other users on the system
that he intends to invite to a meeting, to determine whether a given time
period is available on the respective calendars of the perspective
attendees. However, once the meeting time is set and the prospective
participants notified of the date, time, and subject of the meeting, each
participant must update his own electronic calendar and reply to the
meeting request. While the system can facilitate the request and reply
message process, it is sometimes less frustrating when a negative reply
has to be transmitted to merely use the telephone to arrive at another
mutually convenient time. As a result, a considerable amount of time and
effort is spent by calendar owners replying to requests for participation
in events that are being calendared by other persons.
The cross referenced applications describe various improvements to
electronic calendaring methods for increasing productivity and making the
overall system more appealing to the calendar owner by providing functions
that the calendar owner came to expect and rely on when his calendar was
being kept manually.
In many situations it is desirable that the individual calendar owner have
the ability to designate an alternate to attend a meeting in place of the
designated invitee. This need arises for a number of different reasons
other than the obvious one where the initial invitee cannot attend because
of prior commitments. In many situations, the meeting originator may now
know the name of the specific individual that should attend the meeting
and therefore addresses the meeting notice/invitation to the manager of
the department or function that should be represented.
In other situations the department manager wants to make the assignment on
a meeting by meeting basis so has arranged to receive all notices for
requests for participation by members of his function in events being
calendared. He then must do his own manual type of scheduling and notify
the meeting originator that while he will not attend this meeting an
alternate will attend but that he still wants to be invited to the next
meeting or that the assignment is permanent but he still wants to receive
a copy of the notice. Such sub rosa arrangements between calendar owners
eventually tend to destroy the usefulness of the system and severely
weaken the integrity of its information.
The present invention overcomes the described problems and limitations of
prior art electronic calendaring methods by providing a method in which a
calendar owner can assign an alternate to any meeting to which he has been
invited without in any way affecting his ability to receive notices of
similar meetings in the future.
SUMMARY OF THE INVENTION
In order to minimize the time and effort involved by calendar owners in
replying to requests for participation in a calendared event initiated by
other calendar owners on the network, where the owner/invitee cannot or
does not want to attend but instead wants to send an alternate, the
present invention provides an electronic calendaring method in which a
reply is developed either by the owner interactively or by the system
automatically that reflects the invitees' intention not to attend the
meeting but instead to send an alternate in his place. The method permits
the owner to specify if the alternate is just for the specific meeting
presently being calendared or also for future meetings which are related,
by requesting that the alternate be classified as temporary or permanent.
The method establishes a data structure for storing with the list of names
associated with the event being calendared, the role of each person that
is to attend the meeting and their personal status. When an alternate is
designated, the name of the alternate is added to the names list with the
appropriate role and status data. The name of the owner/invitee remains on
the names list associated with the event but the status and role data is
modified to reflect that he will not attend this meeting but that an
alternate will. If the event is cancelled or modified in any way which
requires the originator to issue a new notice on the system, the notice is
directed to both the original invitee and the alternate and the alternate
is expected to respond if a response is required. The original invitee may
designate that the alternate is a permanent alternate in which case all
future notices which are related to the event will be directed to the
alternate and the original invitee. In this way the original invitee may
keep aware of the events being held should he decide to take some action
relative to the event. The assignment of a permanent alternate is not the
same as providing a permanent substitute since that latter action will
operate to have his name removed from the list.
The automatic assignment of an alternate for a particular event can be
setup in advance by the calendar owner. In this mode the owner establishes
a number of criteria in accordance with the method described and claimed
in cross referenced application Ser. No. 088,033 so that if these criteria
are met a preestablished alternate is assigned with the predetermined role
and personal status data. The alternate is preassigned by the calendar
owner interactively by displaying an option on the screen presented to the
owner for setting up automatic replies that allows selection of this
function and solicits entry of the required information about the
alternate.
This latter feature can be extended to responses to notices sent to
calendar owners which are not individuals but are event supporting
resources, such as conference rooms. This permits a calendar owner to
receive an automatic reply designating a different conference room than he
originally specified in the meeting notice when for some reason the
original is not available. Appropriate fields in the Automatic Response
data structure are provided for storing this data in the system to permit
the automatic reply to be developed under the proper circumstances.
It is therefore an object of the present invention to provide an improved
electronic calendaring method.
A further object of the present invention is to assist owners of electronic
calendars in scheduling calendared events which involve participation of a
number of other calendars owners.
A further object of the present invention is to provide an improved
electronic calendaring method in which a reply by a calendar owner to a
request to participate in an event being calendared by another calendar
owner can reflect the fact that a specific named alternate is to attend
the event in place of the original invitee.
A still further object of the present invention is to provide an electronic
calendaring method in which a calendar owner can establish an automatic
reply to other calendar owners meeting requests, the nature and content of
which reflects that a designated alternate is to attend the meeting and
his role and status relative to the meeting being calendared and future
related meetings depend upon information supplied in the present response.
Objects and advantages, other than those mentioned above, will become
apparent from the following description when read in connection with the
drawing.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of an interactive data processing terminal in
which the method of the present invention may be advantageously employed.
FIG. 2 is a block diagram of the network of terminals of the type shown in
FIG. 1.
FIG. 3 illustrates the display screen that is employed in connection with
the method of the present invention for entering information interactively
into the system relative to an automatic response and a designated
alternate.
FIG. 4a-4c illustrate display screens that are employed by a calendar owner
during the process of calendaring an event on his calendar.
FIG. 5 is a flow chart illustrating various detailed steps of the improved
electronic calendar method involved in developing a reply that reflects
the designation of an alternate.
BRIEF DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 illustrates the functional components of an interactive type data
processing terminal on which the electronic calendaring method of the
present invention may be advantageously employed. The terminal comprises a
processing unit 11 which includes a microprocessor block 12, a
semiconductor memory 13, and a control block 14 which functions to control
input/output operations in addition to the interaction between the micro
processor block 12 and the memory unit 13.
The terminal further includes a group of conventional peripheral units
including a display device 16, a keyboard 17, a printer 18, a disk storage
unit 19, and a modem 20. Since the details of the above described
functional blocks form no part of the present invention and can be found
in the prior art, only a brief functional description of each block is set
forth, along with a description of their interactions, sufficient to
provide a person of ordinary skill in the art with a basis of
understanding applicants' improved electronic calendaring method.
Processing unit 11 corresponds to the "system unit" of a personal computer
system such as the IBM XT or IBM AT type systems. Unit 11 is provided with
an operating system program which may be one of the many versions of DOS
(Disk Operating System) which is normally employed to run the systems. The
operating system program is stored in memory 13 along with one or more
application programs that the user has selected to run. Depending on the
capacity of memory 13 and the size of the application programs, portions
of these programs, as needed, may be transferred to memory 13 from the
disk storage unit 19 which may include, for example, a 30 megabyte hard
disk drive and a diskette drive. The basic function of the disk storage
unit is to store programs and data that are employed by the system and
which may readily be transferred to the memory unit 13 when needed. The
function of the diskette drive is to provide a removable storage function
for entering programs and data into the system, and a vehicle for storing
data in a form that is readily transportable for use on other terminals or
systems.
Display device 16 and keyboard 17 together provide for the interactive
nature of the terminal, in that in normal operation, the interpretation
that the system gives to a specific keystroke by the operator depends, in
substantially all situations, on what is being displayed to the operator
at that point in time.
In some situations, the operator, by entering commands into the system,
causes the system to perform a certain function. In other situations, the
system requests the entry of certain data, generally by displaying a
prompt type of menu/message screen. The depth of the interaction between
the operator and the system varies by the type of operating system and the
application program, but is a necessary characteristic of terminals on
which the method of the present invention may be employed.
The terminal shown in FIG. 1 further includes a printer 18, which functions
to provide hard copy output of data developed or stored in the terminal.
Lastly, the modem 20 functions to transfer data from the terminal of FIG.
1 to a host system through one or more communication links which may be a
commercial type link or a dedicated communication link.
FIG. 2 illustrates a network 21 of interactive type workstations of the
type shown in FIG. 1. As illustrated, the network includes a plurality of
terminals which are interconnected with each other and to a host central
processing unit 23, which in turn is connected via communication link 24
to a second host processing unit 25, which also connects to another
network 26 of interactive workstations. Functionally, the system operates
to allow one terminal to communicate to one or more other terminals using
established communication protocols, so that the various serially
connected communication links are transparent to the operator.
Such systems are well known in the art, and are currently in extensive
commercial use. Since these communication links per se are not part of the
present invention, only those details that are necessary for an
understanding of the calendaring method of the present invention will be
described. It should therefore be assumed in the following description,
that each workstation on the network has a system node address and a "post
office" address, and that to simplify the description, there is only one
individual assigned to each node on the network. It should further be
assumed that conventional communication services are provided by the
system, such as directory listings of individual calendar owners and
shareable resources such as meeting rooms, etc., which require scheduling.
The system shown in FIG. 2 processes information as various types of data
objects such as text data objects, graphic data objects, and calendar data
objects. Each of these data objects are represented by a datastream which
comprises a series of structured fields.
A calendar object datastream has the following sequence of structures.
______________________________________
Begin Document (BDT)
Begin Page (BPG)
Begin Calendar Data (BCL)
Calendar Data Descriptor (CDD) (Optional)
Calendar Data SF (CAD)
Calendar Structures (COCA)
End Calendar Data (ECL)
End Page (EPG)
End Document (EDT)
______________________________________
The format of the datastream for other type data objects contain the begin
document, begin page, end page, and end document data structures.
Structured fields corresponding to those listed above for a calendar
object are also employed for other type objects.
A structured field is a self-describing entity which contains related
groupings of parameter values and triplets. The structured field, as shown
below, has two parts: the Structured Field Introducer and the Structured
Field Content.
##STR1##
The structured field begins with a Structured Field Introducer. The syntax
and semantics of the Structured Field Introducer are defined by the
architecture which governs the datastream in which the structured field is
found. The Structured Field Introducer contains as the first two bytes a
parameter which defines the length of the structured field. It also
contains an identification code which uniquely identifies the structured
field.
The Structure Content portion of each structured field contains structures
and triplets, which give the structured field its meaning. Parameters in
the triples define the attributes of the Calendar Object. Every parameter
has a value either explicitly appearing in a triplet, inherited from a
control structure in the datastream's hierarchy, or implicitly defined as
a default. This default may also be the alternate action value.
Every structure is either required or optional. A required structure
appears in the object because the function of that structure is required
and for proper performance of the function a value is necessary.
An optional structure need not appear in the object either because the
function of that structure is not required or because the function is
required, but default values are acceptable for all parameters.
As shown above, a calendar data (CAD) structured field (SF) precedes the
actual calendar data. A calendar data descriptor (CDD) SF can precede the
CAD SF to provide formatting information for the data that follows.
Calendar data comprises named data structures and named triplets which are
composed of parameters. A parameter is a variable to which a value is
assigned. Parameters can be optional or required. Parameters are also
classified as terminal or non-terminal. A terminal parameter is merely the
last parameter in a string of parameters.
A parameter can have one of three types of values assigned.
1. NUM--This is a number or a numerical value.
2. COD--This is a code assigned a specific meaning.
3. BST--This is a bit string of binary elements, each of which is usually
independent.
In the following discussion it will be assumed that a byte comprises 8 bit
positions numbered 0-7 from left to right, with position 0 being the high
order position. Bit position 0 represents 2**7 (2 to the 7th power), while
bit 7 represents 2**0 (2 to the 0 power).
The various calendar structured fields and calendar triplets are defined by
the following type of table.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
n-m name type v x www
______________________________________
In the FIGURE:
BYTES refers to the position, indexed on zero.
NAME is the name by which reference is made to the parameter.
TYPE denotes the syntax of the parameter by "type," The architected types
NUM, COD, and BST were described earlier.
LGTH denotes the length of the field in terms of the exact number of bytes
or the maximum number of bytes permitted.
OPT refers to the optionality of the parameter's appearance in the
structure or triplet:
O means that the parameter is optional.
R means that the parameter's appearance is required.
If a required parameter is missing, an exception condition exists. The
alternate action is to ignore the structure, self-defining field, or
triplet to which the missing parameter belongs.
Syntactically descriptive material below the FIGURE indicates what
additional restrictions apply to the structure or triplet defined by the
FIGURE.
Calendar structures and calendar triplets which are relevant to the present
invention will be described using the above-described format. After the
structures are described, the display screens that are presented to
calendar owners by the system in order to solicit information when a
calendar owner wants to perform a calendaring function will be described.
A flow chart setting forth the detailed steps of the method of the present
invention will then be described in connection with the program listing of
pseudocode that will assist persons skilled in programming interactive
terminals to implement the method of the present invention.
Since the Automatic Response function operates in response to an invitation
to an event being calendared by another calendar owner, it is necessary to
describe in detail the data structures that are employed by the system in
the process of an owner calendaring an event on his calendar. In the
preferred embodiment, calendar entries are classified into a number of
different types. Since the system contemplates interchanging calendar data
throughout the system, including terminals that are remotely connected,
such as those shown in FIG. 2, entry types and presentation language are
controlled by a defined architecture.
While the same display screen may be employed to solicit the data for a
number of different event types, the data structures and triplets,
required or optional, will vary by event type.
While some of the structures to be described and the triplets associated
with these structures are not directly involved in the "Automatic
Response" function, they have been described in order to provide
background for the reader and a basis for a comprehensive understanding of
the claimed process and its relationship to the processes described and
claimed in the cross-referenced application.
The various calendar object data structures to be described are preceded by
a calendar data structure shown below.
______________________________________
CALENDAR DATA (CAD) STRUCTURE FIELD (SF)
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structured NUM 8 32767 2 R
Field Length
2 Structured COD X`D3` X`D3` 1 R
Field Type1
3 Structured COD X`EE` X`EE` 1 R
Field Type2
4 Structured COD X`5B` X`5B` 1 R
Field Type3
5 Flags BST 0 0 1 R
6-7 Segment NUM 0 32767 2 R
Sequence
Number
8-7+n Calendar Data * * n R
______________________________________
*Values depend on the Calendar Object structure and triplet specification
The Calendar Data SF (CAD) identifies the data as calendar data and
specifies the length of the calendar data. The Calendar Data SF contains,
for example, up to 32767 bytes of calendar structures and calendar
triplets (called "Calendar Data"). Calendar data varies with the function
employed by the generator of the object.
MAJOR CALENDAR STRUCTURES DESCRIPTION
This section describes the major structures that are involved in the
present invention. The structures consist of a mixture of calendar
triplets. The triplets are described in the Calendar Triplets Description
section that follows this section.
The calendar structures are preceded by the Calendar Data Structured field
(CAD). Parameter values specified by the system can be overridden by
parameters specified in calendar data. For example, the Code Page of
Symbols for Displaying and Printing Data.
In the structure description, bits are consecutively numbered from left to
right starting with zero.
The format for all of the structures is the same. The format is shown
below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 LENGTH NUM R
2-3 TYPE COD R
4-n TRPLT1 to R
TRPLTn
______________________________________
where
LENGTH=A two-byte value of the number of bytes in this structure including
byte zero.
TYPE=A two-byte binary number that designates a specific structure
function.
TRPLTl TO TRPLTn=Calendar Structure Triplets.
The length of structures can vary depending on the number of triplets
included.
If the length excludes all or part of an optional parameter in a triplet,
then the value for that parameter and any parameters that follow are not
changed; that is, the LENGTH field is used as specified.
If a structure is invalid or unsupported, an exception is raised.
If the length field excludes a required parameter or triplet, an exception
is raised.
If a structure contains an invalid or unsupported parameter or triplet, an
exception is raised.
MEETING (MTG) STRUCTURE
The meeting structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D#` X`D3` 1 R
Type1
3 Structure COD X`85` X`85` 1 R
Type2
4-3+n Meeting * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The MTG structure provides the field necessary to interchange meeting
information, the scheduling of meetings and requests for meeting
information. It also provides a specific search classification to allow
building a composite calendar for a specified list of calendar owners.
The Valid MTG Triplets are listed below and defined in detail in the
following section.
ERROR ACTION (EAC) - An EAC triplet may occur in any sequence and is
optional.
STRUCTURE ID (SID) - The SID specifies the ID for the metering.An optional
SID may be included to identify a Trigger (TRG) associated with the
meeting.
DATE AND TIME (DTT) - The DTT triplet provides the meeting time(s) and
date(s) and is required. DTT triplets must occur in ascending time(s) and
date(s). A meeting that occurs at non-sequential times can be scheduled by
using more than one DTT triplet specifying the required times.
NAME (NME) - Network Address (NAD), Postal Addresses (PAD) and User Status
(UST) triplets may be used to provide user status and addresses for a
named item. NME triplets and associated NAD, PAD and UST triplets may be
included for both the CALLER (meeting owner) and the ARRANGER (meeting
arranger). The Name Status byte specifies whether or not NAD, PAD and UST
triplets follow the Name triplet which is optional.
USER STATUS (UST) - The UST triplet provides the role and status for the
person named in the NME triplet. This triplet is only valid when it
follows a NME triplet and is optional.
NETWORK ADDRESS (NAD) - The NAD triplet provides the network address for
the person named in the NME triplet and is optional.
POSTAL ADDRESS (PAD) - The PAD triplet provides the mailing address for the
person named in the NME trilet and is optional.
EVENT STATUS (EVS) - The EVS specifies the meeting status and is optional.
TIME STAMP (TMS) - Only one TMS triplet is allowed in the MTG structure and
it is optional.
ENTRY SECURITY (ESL) - If this control is omitted the security level is
PUBLIC. Only one ESL triplet is allowed in the MTG structure and it is
optional.
SET CODED GRAPHIC CHARACTER SET GLOBAL ID (SCG) - The SCG selects the
character set and code page for characters contained in the triplets that
follow the SCG in the calendar structure. The Network Address character
set and code page are not affected by the SCG. The active code page is
restored automatically at the end of the calendar structure.
SUBJECT (SBJ) - The SBJ triplet contains character data describing the
meeting subject. One SBJ triplet is allowed in each MTG structure and it
is optional.
PLACE (PLC) - The PLC triplet contains character data describing the
meeting location. One PLC triplet is allowed in each MTG structure and is
optional.
DETAIL (DTL) - The DTL triplet contains character data describing the
meeting. If the Code Page or character Set is changed in the meeting
description, the DTL triplet must be ended, a SCG triple inserted, and
another DTL triplet built. It is optional.
RSVP (RVP) - The RVP specifies the need for an attendance response from the
meeting invitee and it is optional.
If a MTG structure is received without all required triplets, an exception
exists. The default action is to skip the structure and continue
processing. If a MTG structure contains an unsupported or invalid triplet,
an exception exists. The default action is to skip the triplet and
continue processing. If a MTG structure contains a DTT triplet with dates
and times not in ascending order or if the optional SCG triplet occurs at
a position that does not immediately precede a triple with text data (DTL,
SBJ, PLC), an exception exists. The default action, in both cases, is to
ignore the triplet and continue processing.
NAMES LIST (NML) DATA STRUCTURE
The names list data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D3` X`D3` 1 R
Type1
3 Structure COD X`8A` X`8A` 1 R
Type2
4-3+n NML * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The NML structure provides the fields to support a name, associated
addresses and status. The NML may contain a list of items, such as an
invitees list, by concatenating Name (NME), Address (ADR) and User Status
(UST) sequences. The list may include one or more than one name and
associated information.
The following Valid NML Triplets for the NML DS were described in
connection with the MTG structure.
ERROR ACTION, STRUCTURE ID, TIME STAMP, ENTRY SECURITY, SET CGCSGID, NAME,
USER STATUS, NETWORK ADDRESS AND POSTAL ADDRESS.
The Date and Time (DTT) triplet is not valid.
The following triplet, however, is optional for the Names List data
structure.
NAMES LIST TYPE (NLT) - Only one NLT triplet is allowed in the Names List
structure. The NLT triplet specifies the type of data contained in the
Names List. If the NLT is not specified, the list contains a list of names
and or status and/or addresses that are not necessarily in one of the
categories defined by the NLT triplet.
If a NML structure is received without a Structure ID triplet, an exception
exists. The default action is to skip the structure and continue
processing. If a NML structure contains an unsupported or invalid triplet,
an exception exists. The default action is to skip the triplet and
continue processing. Each sequence of the Names List structure triplets
must occur in the listed order.
Optional triplets may be omitted from any sequence. If a NML structure is
received with a triplet out of sequence, an exception exists. The default
action is to skip the structure and continue processing. The
above-described processing for handling exceptions is standard for most
structures and therefore can be assumed for the following items.
VIEW SELECT (VSL) DATA STRUCTURE
The View Select data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D3` X`D3` 1 R
Type1
3 Structure COD X`95` X`95` 1 R
Type2
4-3+n VSL Triplets * * n R
______________________________________
*Values depend on the triplet specification.
The VSL structure provides a way to request calendar views for specific
category(s) and timespan(s).
The Valid VSL Triplets previously described include the ERROR ACTION (EAC),
USER DEFINED FIELD (UDF) and DATE and TIME (DTT) triplets.
The following triplet is also optional and valid.
ENTRY CATEGORY (ECT) - The ECT selects the category(s) for the calendar
entry(s) to be selected in the view request. Only one ECT is allowed in a
View Select structure. When more than one category is selected in the ECT,
the view returned will contain the selected categories. If both the ECT
and UDF triplet are omitted, all entries in the selected timespan will be
returned.
The DTT triplet dates and times must occur in ascending order. The first
DTT processed must provide the earliest data and time block. The last DTT
processed must provide the latest date and time block. The first DTT also
provides the begin date and time for the timespan selected.
When the optional ECT triplet is present, the VSL triplets must occur in
the order ECT, DTT.
AUTO RESPONSE (ARS) DATA STRUCTURE
The Auto Response data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D3` X`D3` 1 R
Type1
3 Structure COD X`72` X`72` 1 R
Type2
4-3+n Auto * * n R
Response
Triplets
______________________________________
The ARS structure provides the fields necessary to interchange automatic
response information. It allows the use of a network address(NAD), A
Meeting or Appointment Structure ID (SID), A Priority (UDF) or a User
Defined Field (UDF) specification to initiate an automatic response.
The valid ARS triplets include the following: ERROR ACTION (EAC,) SET
CGCSGID (SCG), STRUCTURE ID (SID), NAME (NME), USER STATUS (UST), NET WORK
ADDRESS (NAD), POSTAL ADDRESS (PAD), TIME STAMP (TMS), ENTRY SECURITY
(ESL), USED DEFINED FIELD (UDF), RESPONSE (RSP).
If a NAD, a SID, A PRIORITY UDF, or A UDF, received as part of an
invitation and request to attend an event being calendared, satis | | |
