SIPPING WG R.G. Crespo
Internet-Draft UTL
<draft-cl-sipping-fi-resolution-00.txt> L. Logrippo
Intended Status: Experimental UQO
Expires April 15, 2009 October 15, 2008
Distributed Resolution of Feature Interactions for
Internet Applications
<draft-cl-sipping-fi-resolution-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draff will expire on April 15, 2009.
Abstract
Internet applications have been enhanced with many features.
A feature may be defined as a unit of functionality in a system, having
a self-contained role.
However, the introduction and modification of features may result in
undesired behaviors, and this effect is known as feature interaction -
FI for short.
This document specifies the architecture of a distributed feature mana-
ger that proposes the resolution of feature interactions. The resolu-
tion may be done locally, or with cooperation between different nodes.
The resolution method is left to the implementation. In this document
Crespo & Logrippo Expires April 2009 [Page 1]
Resolution of Feature Interactions October 15, 2008
we provide an example of one resolution method, based on feature
interdiction, as described by a set of deontic formulas.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. FI major problems . . . . . . . . . . . . . . . . . . . . 3
1.2. FI classification . . . . . . . . . . . . . . . . . . . . 4
1.3. Conventions of this document . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol specification . . . . . . . . . . . . . . . . . . . . 5
3.1. Feature representation . . . . . . . . . . . . . . . . . . 6
3.2. Candidate message format . . . . . . . . . . . . . . . . . 7
3.2.1. Header part . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Information part . . . . . . . . . . . . . . . . . 8
3.3. Advice message format . . . . . . . . . . . . . . . . . . 8
3.4. Request message format . . . . . . . . . . . . . . . . . . 9
3.5. Reply message format . . . . . . . . . . . . . . . . . . . 9
4. Feature resolution . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Constraint relationships . . . . . . . . . . . . . . . . . 10
4.1.1. Local constraints . . . . . . . . . . . . . . . . . 11
4.1.2. Chain constraints . . . . . . . . . . . . . . . . . 11
4.1.3. Point-to-point constraints . . . . . . . . . . . . 11
4.2. Losing information . . . . . . . . . . . . . . . . . . . . 11
4.3. Features represented by multiple actions . . . . . . . . . 11
4.4. Final selection . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Registries for messages between LA and LIRAdv . . . . . . 12
6.2. Registries for messages between LIRAdv and RIRAdv . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The purpose of this draft is to document a method to resolve feature
interactions, which may occur in Internet applications. The method is
based on the use of a feature manager, designated as Interaction
Resolver Advisor (IRAdv). IRAdvs may cooperate to resolve particular
interactions. This document focuses on the interaction between the
applications and the IRAdvs, and between IRAdvs.
The implementation of the IRAdvs is left unspecified, although we
describe one possible implementation based on a set of interdiction
formulas.
Crespo & Logrippo Expires April 2009 [Page 2]
Resolution of Feature Interactions October 15, 2008
Internet applications provide sets of basic services. For example,
the Email protocol provides two basic services: sending a message to
another user and reading a message from another user.
Internet applications have been enhanced with many features, defined
as units of functionality existing in a system and perceived as
having self-contained roles. For example, ForwardMessage and
AutoResponder are popular Email features. ForwardMessage forwards
all incoming Email messages to another user. AutoResponder reads the
incoming messages and sends automatically a notification message to
the Email originators, for example notifying them that the recipient
is absent on vacation.
The combination of features, which work fine alone, may result in
undesired behaviors and this problem is known as feature interaction,
or FI for short. For example, suppose that Bob instructs the Email
server to execute the ForwardMessage feature, forwarding all messages
to Carl. A message that Alice sends to Bob is sent again to Carl.
Suppose also that Carl subscribes to the AutoResponder feature.
Thereafter, the Email server of Carl accepts Alice message and sends
a notification message to Bob, not to the message originator (Alice).
This result goes against the goal of the AutoResponder feature, which
is to notify the originator that Carl is away. The Email server of
Bob, when it receives the notification message, forwards it back to
Carl. The Email server of Carl detects a loop, another undesired
behavior, and discards the notification message.
In this draft, we adopt SMTP definitions [2] for originator and
recipient.
FIs may occur for a single user: for example, ForwardMessage and
ReadMessage basic services interact (if a message arrives, should it
be forward to another user, or should it be stored in the Email
server?). FIs may involve several users, such as the one between the
ForwardMessage and AutoResponder features.
FIs may occur within a single application node, such as the one
between the AutoResponder and FilterMessage. FIs may also occur
among different application nodes, an example is mutual
ForwardMessage features.
The FI problem, first identified in circuit-switched networks, has
been studied in many Internet applications, such as Email [3], VoIP
[4], WWW [5] and networked home appliances [6].
1.1. FI major problems
Three basic problems have been studied: avoidance, detection and
Crespo & Logrippo Expires April 2009 [Page 3]
Resolution of Feature Interactions October 15, 2008
resolution.
* Avoidance means to intervene at protocol or design stages to
prevent FIs, before features are executed. The distributed nature
of the Internet, with multi-vendor and multi-provider environments,
and the end user capability to program and tailor features, make it
impossible to rely on avoidance.
* Detection aims at the identification of FIs, with suitable
methods. A review of several existing methods of FI detection is
given in [7].
* In the resolution, actions are exercised over already detected
FIs. Three approaches have been explored for FI run-time
resolution: one phase, two phase and negotiation.
The one phase approach uses feature managers to decide which feature
is executed, according to tables or trees. Although simple, the one
phase approach requires knowledge about low-level details, suffers
from the scalability problem, and reveals problems in the resolution
of multiple user FIs.
In the two phase approach, the feature is executed in an isolated
environment and actions are taken in case of FI. The isolated
environment is impractical in the Internet.
The distributed character of the Internet makes direct negotiation
the most suitable approach.
In this draft, we specify an Interaction Resolver Adviser (IRAdv),
which is
* scalable, i.e., such that increasing the number of Internet
applications and increasing the number of subscribed features does
not degrade significantly the resolution performance,
* accepts partial resolution, i.e., it will work even if some nodes
do not reply to requests sent by other IRAdvs - because they may be
down or because IRAdvs have not been installed,
* independent of the feature implementation, and
* unique for all Internet applications.
1.2. FI classification
Several taxonomies have been produced to classify different types of
FI. Here we adopt the classification of [9], where FIs are
Crespo & Logrippo Expires April 2009 [Page 4]
Resolution of Feature Interactions October 15, 2008
classified by the nature of the interaction, as well as by the cause
of the interaction.
We are especially concerned with the nature of the interactions,
according to the number of parties involved in the interactions
(single or multiple), the number of network components involved in
the interactions (single or multiple), and the kind of features
involved in the interactions (custom or system).
1.3. Conventions of this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are to be
interpreted as described in RFC 2119 [1] and indicate requirement
levels for compliant implementations.
1.4 Terminology
FI: Feature interaction
FIRP: Feature Interaction Resolution Protocol
IETF: Internet Engineering Task Force
IRAdv: Interaction Resolver Adviser
LIRAdv: Local Interaction Resolver Adviser
RIRAdv: Remote Interaction Resolver Adviser
WWW: World Wide Web
2. Architecture
The architecture model that we propose for a distributed resolution
of FIs is depicted in figure 1. The architecture model adopts the
client-server model.
Crespo & Logrippo Expires April 2009 [Page 5]
Resolution of Feature Interactions October 15, 2008
+---------------------------------+
| Application |
| |
| +-----------+ + ----------+ |
| | Feature 1 | ... | Feature N | |
| +-----------+ +-----------+ |
| |
+---------------------------------+
^ |
| | Candidates
| |
| | +-------+ +-------+
| +->| | Request | |
| | IRAdv |-------->| IRAdv |
+------| |<--------| |
Advice | | Reply | |
| | | |
+-------+ +-------+
Figure 1 Architecture model
When an application has a request for a service, incoming or outgo-
ing, the application may identify more than one feature as candidate
for service execution. The application asks IRAdv for advice on
which feature the application should execute that will not generate
inconsistent behaviors.
IRAdvs may request other IRAdvs for additional information. Their
reply will assist the requesting IRAdv to identity the advice, to be
returned to the application.
3. FIRP specification
This section provides the detailed description of the FIRP-Feature
Interaction Resolution Protocol. The entities are the Local Applica-
tion (LA), the Local IRAdv (LIRAdv) and the Remote IRAdv (RIRAdv).
The protocol between the Application (the client) and the Local IRAdv
(the server) is depicted in figure 2.
* First, upon the arrival of an incoming message or the generation
of an outgoing message, the application sends to the LIRAdv a set
of feature candidates for execution, together with the application
status.
* LIRAdv may request other RIRAdv for a certain kind of permission
to execute the feature. In this case, RIRAdv returns a Reply. With
Crespo & Logrippo Expires April 2009 [Page 6]
Resolution of Feature Interactions October 15, 2008
consideration of this reply, LIRAdv selects the feature which, when
executed by LA, does not generate FIs.
* Finally, LIRAdv advises LA on which feature it must execute.
LA LIRAdv RIRAdv
| | |
+----------------------+ | |
|Feature identification| | |
+----------------------+ | |
| Candidates | |
|------------------>| |
| (Features,Status) | |
| | Request |
| |------------->|
| | (Permission) |
| | Reply |
| |<-------------|
| | (Permission) |
| +-----------------+ |
| |Feature selection| |
| +-----------------+ |
| Advice | |
|<------------------| |
| (Feature) | |
Figure 2 Resolution procedure
The location of IRAdvs is a matter of implementation: each applica-
tion node may have installed one IRAdv, or one IRAdv may serve sev-
eral application nodes. In both cases, when receiving requests from
other IRAdvs, the remote IRAdvs should have access to information
from the application nodes that they are serving.
3.1 Feature representation
The number of features in a system may be large. For example, about
eight hundred features are known in telephone systems [8]. Short
lists of 17 telecommunication features, easily adapted to VoIP [9],
and the specification of 10 Email features [3] are available in the
literature. Hence, there is a need to identify a compact representa-
tion of features, to avoid a large matrix of relationships in the FI
resolver.
Compact feature representations have been proposed in [10] and [11].
We adopt here the feature representation of [10], with a set of basic
Crespo & Logrippo Expires April 2009 [Page 7]
Resolution of Feature Interactions October 15, 2008
and abstract actions that a feature can execute. Actions are depicted
in table 1. All actions have one parameter that may be
* _init, the node that started the message,
* _dest, the node to whom the message should be delivered (that may
be changed later, for example as the result of a forward),
* _self, the node currently processing the message.
Table 1 Feature basic actions
+-----------------+------------------------------------------------+
| Name | Purpose |
+-----------------+------------------------------------------------+
|Accept(_init) | The node accepts the message |
+-----------------+------------------------------------------------+
|Deny(_init) | The node rejects the message |
+-----------------+------------------------------------------------+
|Display(_init) | The node displays the originator and waits for |
| | the recipient to confirm message acceptance |
+-----------------+------------------------------------------------+
|Emergency(_init) | The node must accept the message, with highest |
| | priority |
+-----------------+------------------------------------------------+
|Forward(_dest) | The node redirects the message to another node |
+-----------------+------------------------------------------------+
|Send(_dest) | The node initiates a message to another node |
+-----------------+------------------------------------------------+
|Wait(_init) | The node puts the message on hold, for later |
| | processing |
+-----------------+------------------------------------------------+
Two different features may be represented by the same basic actions.
For example, the VoIP CFA-Call Forward Always and CFB-Call Forward if
Busy features are both represented by the Forward action when the
user is busy.
One feature may be represented by more than one action. For example,
the Email AutoResponder feature is represented by the join of actions
Accept and Send.
3.2 Candidate message format
When an application has a request for a service, incoming or outgo-
ing, more than one feature may be selected as candidate for service
execution. Then, the application sends to the IRAdv attached to its
Crespo & Logrippo Expires April 2009 [Page 8]
Resolution of Feature Interactions October 15, 2008
node a message with a structure divided in two parts:
* Header part, containing information about the message and the
involved parties,
* Information part, containing specific information about each
selected feature.
3.2.1. Header part
The header part is divided into five fields: AP, Initial-Addr, Chain-
Addr, AS and CD.
* ApplicationPort field (AP) indicates which application requires
advice.
AP value is the port number attached to the associated application
protocol, as registered by IANA. For example, Email applications
follow the SMTP protocol [2] and communicate through port 25.
* Initial Address (Initial-Addr) field contains the address of the
user that has initiated the message.
The Initial-Addr is set by the originator application, and must
remain unchanged until the message is last processed. Actions with
_init parameter bind their value to Initial-Addr value.
* Chain Address field (Chain-Addr) contains the list of IP
addresses of all nodes that have processed the message, including
the originator. This field can be useful to detect message loop-
ing. The originator node starts an empty Chain-Addr field. All
successive nodes, including the originator, append their IP
addresses to the Chain-Addr field.
* ApplicationStatus field (AS) provides information about the
application status.
The structure and the meaning of the application status depend on
the implementation of the application and of the IRAdv. An example
of application status is the predicate loop(_self) which is true if
the processing node finds its own IP address in the Chain-Addr
value.
* ConfirmDirective field (CD) indicates the kind of confirmation to
be asked of the originator node. CD field is intended for the
implementation of access control policies, such as parental con-
trol. In this document we do not focus on security issues, such as
authorisation and data integrity.
Crespo & Logrippo Expires April 2009 [Page 9]
Resolution of Feature Interactions October 15, 2008
Table 2 depicts the possible values for the CD field.
Table 2 ConfirmDirective field values
+------------+----------------------------------------------------+
| Value | Purpose |
+------------+----------------------------------------------------+
|None | Message may be processed without originator |
| | knowledge |
+------------+----------------------------------------------------+
|AllNodes | All nodes must ask, from the originator, |
| | permission to process the message |
+------------+----------------------------------------------------+
|Destination | Only the final destination node must ask, from the |
| | originator, permission to process the message |
+------------+----------------------------------------------------+
CD-value should be transmitted with the message. Section 4.2 dis-
cusses the case when, for some reason, the CD-value is unavailable.
3.2.2. Information part
The information part is divided into two fields: FC and Act.
* FeatureCode field (FC) is an unique identifier of the feature
candidate for execution.
The purpose of the FC field is to link features to the actions that
represent them.
* Action field (Act) is a list of action codes, that represent the
features identified in the FC field.
Each action code must be followed by the IP addresses of the action
parameters. The Action parameters, listed in table 1, are: _init,
_dest and _self.
3.3. Advice message format
Local IRAdv returns to the application the feature code that it
should execute. In case of failure in FI resolution, IRAdv must
return to the application the special code NO_ADVICE.
3.4. Request message format
When an IRAdv receives a candidate message, it may be necessary for
resolution of FIs to ask another IRAdv for permission to execute the
Crespo & Logrippo Expires April 2009 [Page 10]
Resolution of Feature Interactions October 15, 2008
feature. The information exchange is sent through a request message,
which is linked to the candidate message.
Every request message contains five fields: FC, AP, CC, Initial-Addr
and Destination-Addr.
* FeatureCode field (FC) is a unique identifier for the feature.
The FeatureCode value is equal to the value in the corresponding
field in the linked Candidate message.
* ApplicationPort field (AP) indicates the application concerned by
the request. The AP value must be equal to the value in the corre-
sponding field in the candidate message.
* ConfirmationCode field (CC) indicates the kind of permission
required, or its result. Table 3 depicts the possible values for
the CC field.
Table 3 ConfirmationCode values
+--------------------+------------------------------------------+
| Value | Purpose |
+--------------------+------------------------------------------+
|Delivery_request | Request permission to accept the message |
+--------------------+------------------------------------------+
|Delivery_acceptable | Message may be delivered |
+--------------------+------------------------------------------+
|Delivery_denied | Message must not be delivered |
+--------------------+------------------------------------------+
For the Request message, the only acceptable value of the CC field
is Delivery_request
* Initial Address field (Initial-Addr) contains the address of the
user that initiates, or has initiated, the message. The Initial-
Addr value is equal to the same field in the linked Candidate mes-
sage.
* Destination Address field (Destination-Addr) contains the address
of the intended destination partner. The Destination-Addr value is
equal to the value in the corresponding field in the linked Candi-
date message.
3.5. Reply message format
The Reply message format is equal to the Request message format. The
only difference between Request and Replay messages is the CC value.
Crespo & Logrippo Expires April 2009 [Page 11]
Resolution of Feature Interactions October 15, 2008
For Reply message, the CC value may only be equal to Delivery_accept-
able or Delivery_denied
IRAdvs must be aware that other IRAdvs may not reply to their
requests. For example, remote nodes may be temporarily down, or may
not have IRAdv installed. If the local IRAdv does not receive a
reply to a request, it may produce a different advice. This problem
is discussed in section 4.2
4. Feature resolution
The method for selecting feature candidates that would not produce
FIs is left to the implementation.
Here we describe the implementation presented in [10], based on two
steps:
* In the first step, the filtering phase, a set of constraint for-
mulas is evaluated over the actions that each feature candidate
represents. This step is described in sections 4.1 to 4.3.
The filtering phase is implemented with support of a set of con-
straint formulas. If satisfied, a constraint formula marks some
actions as interdicted. The result of the first step is the elimi-
nation of a subset of feature candidates for execution. The remain-
ing feature candidates are submitted to the second step.
* In the second step, the selection phase, one feature is selected
for execution advice. This step is described in section 4.4
4.1. Constraint relationships
Constraint relationships are formulas expressed in the first-order
predicate language, extended with the interdiction operator I. Logi-
cal connectives are listed in table 4
Crespo & Logrippo Expires April 2009 [Page 12]
Resolution of Feature Interactions October 15, 2008
Table 4 Logical connectives
+-----------+--------+---------------------+
|Connective | Arity | Meaning |
+-----------+--------+---------------------+
| AND | Binary | Formula conjunction |
+-----------+--------+---------------------+
| OR | Binary | Formula disjunction |
+-----------+--------+---------------------+
| IMPLY | Binary | Formula implication |
+-----------+--------+---------------------+
| NOT | Unary | Formula negation |
+-----------+--------+---------------------+
| I | Unary | Action removal |
+-----------+--------+---------------------+
The operator precedence, which may be overridden by the use of par-
entesis, is as follows
* Highest precedence for unary operators.
* Intermediate precedence for conjunction and disjunctive opera-
tors.
* Lowest precedence for the implication operator.
The form of the formula is
Requests AND Conditions IMPLY Restrictions
* The Requests part is a conjunction of actions, representing fea-
tures selected by the application as candidates for execution.
* The Conditions part identifies the values that the application
status, or message status, may have to hold.
By default, this part is considered to be true.
* The Restrictions part identifies the single action, or the join
of actions, whose execution is forbidden.
In this part we use the Interdiction unary connective, where I act
means that action act cannot be executed.
There are three different types of constraint formulas which apply to
different layouts of the nodes that participate in the resolution. We
call these local, chain and point-to-point constraints.
Crespo & Logrippo Expires April 2009 [Page 13]
Resolution of Feature Interactions October 15, 2008
4.1.1. Local constraints
Local constraints are directed to the resolution of single user FIs.
For example, the formula that gives a Deny action a priority greater
than the Accept action is
Accept(_init) AND Deny(_init) IMPLY I Accept(_init)
4.1.2. Chain constraints
Chain constraints are oriented to the resolution of multiple FIs,
with no request for permission from another IRAdv.
For example, the formula that forbids a message to enter a loop
through Forward actions is
Forward(_dest) AND loop(_self) IMPLY I Forward(_dest)
4.1.3. Point-to-point constraints
Chain constraints are directed to the resolution of multiple user
FIs, with request for permission from another IRAdv.
For example, the formula that resolves ReadMail and FilterDestination
FI is
Accept(_init) AND NOT permission(_init) IMPLY I Accept(_init)
4.2. Losing information
Because IRAdvs may not work properly in all intervening nodes, in
some cases a reply may not be returned. IRAdv must always return an
advice to the application, therefore a default value for the reply
must be considered. The default value may depend on the recipient
application. For example, the content of some WWW pages may require
an explicit confirmation from the originator and the default reply
value for permission(_init) request would be false.
4.3. Features represented by multiple actions
Actions of different features are connected in the Request and Inter-
diction parts by the AND logical operator.
The join predicate is needed because some features can be represented
by several actions, and we do not want actions to be transferred from
one feature representation to another. If A,B and C are actions,
join(A,B) AND C is equivalent to C AND join(A,B) or to C AND
Crespo & Logrippo Expires April 2009 [Page 14]
Resolution of Feature Interactions October 15, 2008
join(B,A), but not to A AND join(B,C).
For example, to interdict AutoResponder feature to send a reply to
the postmaster, the formula is
join(Accept(_init),Send(_dest)) AND _dest=postMaster
IMPLY I Send(postMaster)
The fact that several action may be joined in a features raises the
question of what will happen if only some actions in a feature are
interdicted. We have identified three different approaches for fea-
ture interdiction: maximization, conditional and survival.
* The interdiction maximization approach interdicts a feature even
if only one of the actions that represents it in the join is inter-
dicted.
* The conditional interdiction approach interdicts an action join
if some of the actions that are joined are interdicted, but not
all, and there are actions outside the join that are not inter-
dicted.
* The survival maximization approach interdicts an action join only
when all of the actions that are joined are interdicted.
4.4. Final selection
The set submitted to the selection phase represent the features that
do not generate FI.
IRAdv implementation can adopt any algorithm capable of selecting the
feature to be presented to the application. If necessary, feature
parameters may be updated.
An algorithm could mark all candidate features for elimination. This
problem is not addressed here.
5. Security Considerations
There are several security considerations associated with this pro-
posal. Feature interaction results in unexpected behaviors. The
unexpected behaviors may include access to confidential information.
The FI resolution is targeted to avoid such unexpected behaviors but,
itself, may raise security concerns.
Information exchange between IRAdvs must be properly authenticated.
data Moreover, data corruption must be avoided by adopting integrity
mechanisms.
Crespo & Logrippo Expires April 2009 [Page 15]
Resolution of Feature Interactions October 15, 2008
6. IANA Considerations
To allow the development of FI resolvers, as specified in this docu-
ment, by different developers, registries must be assigned for a num-
ber of message fields. The message fields, defined by the FIRP proto-
col, are explained in section 3 of this document. Also, IRAdv pro-
vides a service through a contact port, to be defined by IANA.
6.1. Registries for messages between LA e LIRAdv
The messages sent by LA to LIRAdv are specified in section 3.2 of
this document. The messages sent by LIRAdv to LA are specified in
section 3.3 of this document.
* Feature basic actions, such as listed in table 1.
* Application status, to which the application assigned a true
value.
* ConfirmDirective values, as listed in table 2.
* Registry value for NO_ADVICE, for the case when LIRAdv is unable
to select one feature for execution.
6.2. Registries for messages between LIRAdv and RIRAdv
Registries must be assigned to a number of fields for the messages
exchanged between the LIRAdv and the RIRAdv. Such messages are speci-
fied in sections 3.4 and 3.5 of this document.
* ConfirmationCode values, as listed in table 3.
7. Acknowledgements
This document is based on discussions with Tom Gray of PineTel, and
Jacques Sincennes of the University of Ottawa, who contributed sig-
nificantly to the ideas presented here.
8. References
8.1 Normative references
[1] S. Bradner, Key words for use in RFCs to Indicate Requirement
Levels, BCP 14, RFC 2119, March 1997.
8.2 Informative references
[2] J. Klensin, Simple Mail Transfer Protocol, RFC 5321, October
Crespo & Logrippo Expires April 2009 [Page 16]
Resolution of Feature Interactions October 15, 2008
2008.
[3] R. Hall, Feature Interactions in Electronic Mail, 5th Intl Work-
shop on Feature Interactions in Telecommunication and Software Sys-
tems, pp. 232-246, September 1998.
[4] J. Lennox, H. Schulzrinne, Feature Interactions in Internet Tele-
phony, 6th Intl Workshop on Feature Interactions in Telecommunica-
tion and Software Systems, pp. 38-50, May 1998.
[5] M. Weiss, Feature Interactions in Web Services, 7th Intl Workshop
on Feature Interactions in Telecommunication and Software Systems,
pp. 149-156, 2003.
[6] M. Nakamura, Y. Igaki, K.-i. Matsumoto, Feature Interactions in
Integrated Services of Networked Home Appliances, 8th Intl Confer-
ence on Feature Interactions in Telecommunications and Software
Systems, pp. 236-251, 2005.
[7] M. Calder, M. Kolberg, E. Magill, S. Reiff-Marganiec, Feature
interaction: a critical review and considered forecast, Computer
Networks, Vol. 41, No. 1, pp. 115-141, January 2003.
[8] K.P. Pomakis, J.M. Atleem Reachability analysis of feature inter-
actions: a progress report, ACM SIGSOFT Intl Symposium on Software
Testing and Analysis, pp. 216-223, January 1996.
[9] E.J. Cameron, N. Griffeth, Y.-J. Lin, M.E. Nilson, W.K. Schnure,
Feature interaction benchmark for IN and beyond, Intl Workshop on
Feature Interactions in Telecommunications Systems, pp. 1-23, 1994.
[10] R.G. Crespo, M. Carvalho, L. Logrippo, Distributed Resolution of
Feature Interactions for Internet Applications, Computer Networks,
Vol. 51, No. 2, pp. 382-397, February 2007.
[11] A.F. Layouni, L. Logrippo, J.T. Turner, Conflict Detection in
Call Control Using First-Order Logic Model Checking, 9th Intl Con-
ference on Feature Interactions in Software and Communications Sys-
tems, September 2007.
Author's Addresses
Rui Gustavo Crespo
Electrical and Computer Engineering Department
Technical University of Lisbon
Av. Rovisco Pais, 1049-001 Lisboa
Portugal
Crespo & Logrippo Expires April 2009 [Page 17]
Resolution of Feature Interactions October 15, 2008
Phone: +351 - 21 8417 626
EMail: R.G.Crespo@comp.ist.utl.pt
Luigi Logrippo
Departement de Informatique et Ingenierie
Universite du Quebec en Outaouais
Case Postale 1250, Succ. B, Gatineau QC J8X 3X7
Canada
Phone: (819) 595-3900 x 1885
Email: luigi@uqo.ca
Crespo & Logrippo Expires April 2009 [Page 18]
Resolution of Feature Interactions October 15, 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Crespo & Logrippo Expires April 2009 [Page 19]