-- Module IN-SDF-SDF-Operations (Q.1248.5:07/2001)
-- See also ITU-T Q.1248.5 (07/2001)
-- See also the index of all ASN.1 assignments needed in this document

IN-SDF-SDF-Operations {itu-t recommendation q 1248 modules(1)
  in-sdf-sdf-ops-args(18) version1(0)} DEFINITIONS ::=
BEGIN

IMPORTS
  ds-UsefulDefinitions, ros-InformationObjects, scf-sdf-Additional-Definitions
    FROM IN-object-identifiers {itu-t recommendation q 1248 modules(1)
      in-object-identifiers(0) version1(0)}
  directoryShadowAbstractService, disp, distributedOperations,
    enhancedSecurity, directoryAbstractService
    FROM UsefulDefinitions ds-UsefulDefinitions
  CoordinateShadowUpdateArgument, CoordinateShadowUpdateResult,
    UpdateShadowArgument, UpdateShadowResult, RequestShadowUpdateArgument,
    RequestShadowUpdateResult, shadowError, RefreshInformation,
    ShadowingAgreementInfo
    FROM DirectoryShadowAbstractService directoryShadowAbstractService
  id-opcode-coordinateShadowUpdate, id-opcode-updateShadow,
    id-opcode-requestShadowUpdate
    FROM DirectoryInformationShadowProtocol disp
  ChainingArguments, ChainingResults, ReferenceType, dsaReferral,
    ContinuationReference, AccessPoint, MasterOrShadowAccessPoint,
    AccessPointInformation
    FROM DistributedOperations distributedOperations
  OPTIONALLY-PROTECTED{}, dirqop
    FROM EnhancedSecurity enhancedSecurity
  referral
    FROM DirectoryAbstractService directoryAbstractService
  OPERATION, ERROR
    FROM Remote-Operations-Information-Objects ros-InformationObjects
  in-Execute, in-AddEntry, in-DirectoryBind, in-RemoveEntry, in-Search,
    in-ModifyEntry
    FROM IN-SCF-SDF-Additional-Definitions scf-sdf-Additional-Definitions;

-- IN X.500 DISP definition
IN-ShadowingAgreementInfo ::=
  ShadowingAgreementInfo(WITH COMPONENTS {
                           ...,
                           master  ABSENT
                         })

-- shadowSubject specifies the subtree, entries and attributes to shadow. The components of 
-- UnitOfReplicationare defined in section 9.2 of Recommendation X.525.
-- updateMode specifies when updates of a shadowed area are scheduled to occur. The components of 
-- updateMode are defined in section 9.3 of Recommendation X.525.
-- master contains the access point of the DSA containing the mastered area. "As this information is 
-- already known by the DSA it is not required for IN."
-- secondaryShadows permits secondary shadow information to be subsequently supplied to the shadow 
-- supplier. 
-- The secondary shadows are ignored in the IN context (assumption 5), then this component should not 
-- be included.
in-DSAShadowBind OPERATION ::=
  in-DirectoryBind

-- An IN-DSAShadowBind operation is used at the beginning of a period of providing shadows.
in-CoordinateShadowUpdate OPERATION ::= {
  ARGUMENT  IN-CoordinateShadowUpdateArgument
  RESULT    IN-CoordinateShadowUpdateResult
  ERRORS    {shadowError}
  CODE      id-opcode-coordinateShadowUpdate
}

-- The IN-CoordinateShadowUpdate operation is used by the shadow supplier to indicate the shadowing 
-- agreement for which it intends to send updates.
IN-CoordinateShadowUpdateArgument ::=
  CoordinateShadowUpdateArgument
    (WITH COMPONENTS {
       ...,
       toBeProtected  (WITH COMPONENTS {
                         ...,
                         updateStrategy  (standard:total | standard:incremental)
                       })
     })

IN-CoordinateShadowUpdateResult ::=
  CoordinateShadowUpdateResult(WITH COMPONENTS {
                                 ...,
                                 null  PRESENT
                               })

-- The various parameters have the meanings defined below:
-- a)	The agreementID argument identifies the shadowing agreement.
-- b)	The lastUpdate argument indicates the shadow supplier's understanding of the time at which
-- 	the last update for this agreement was sent and is the time as provided by the shadow supplier 
-- 	DSA. This argument may only be omitted in the first instance of either a 
-- 	IN-CoordinateShadowUpdate or IN-RequestShadowUpdate operation for a particular
--	shadowing agreement
-- c)	The updateStrategy argument identifies the update strategy the shadow supplier intends to use 
-- 	for this update. For IN CS-4, a total or incremental replacement strategy should be used. 
-- 	The "NoChanges" option will not be used.
-- d)	The securityParameters argument is defined in 7.10 of ITU-T Rec. X.511 | ISO/IEC 9594-3.
in-UpdateShadow OPERATION ::= {
  ARGUMENT  IN-UpdateShadowArgument
  RESULT    IN-UpdateShadowResult
  ERRORS    {shadowError}
  CODE      id-opcode-updateShadow
}

-- An IN-UpdateShadow operation is invoked by the shadow supplier to send updates to the shadow 
-- consumer for a unit of replication. Prior to this operation being initiated, a 
-- IN-CoordinateShadowUpdate or IN-RequestShadowUpdate operation must have been successfully 
-- completed for the identified shadowing agreement.
IN-UpdateShadowArgument ::=
  UpdateShadowArgument
    (WITH COMPONENTS {
       ...,
       toBeProtected  (WITH COMPONENTS {
                         ...,
                         updatedInfo  (IN-RefreshInformation)
                       })
     })

IN-UpdateShadowResult ::=
  UpdateShadowResult(WITH COMPONENTS {
                       ...,
                       null  PRESENT
                     })

-- The various parameters have the meanings as defined below:
-- a)	The agreementID identifies the shadowing agreement that has been established.
-- b)	The updateTime argument is supplied by the shadow supplier. This time is used during the 
-- 	next IN-CoordinateShadowUpdate or IN-RequestShadowUpdate to ensure that the shadow 
-- 	supplier and shadow consumer have a common view of the shadowed information.
-- c)	The updateWindow argument, when present, indicates the next window during which the 
-- 	shadow supplier expects to send an update.
-- d)	The updatedInfo argument provides the information required by the shadow consumer to 
-- 	update its shadowed information. The semantics of the information conveyed in this parameter 
-- 	shall result in the shadow consumer reflecting the changes supplied. 
-- e)	The securityParameters argument is defined in 7.10 of ITU-T Rec. X.511 | ISO/IEC 9594-3.
IN-RefreshInformation ::=
  RefreshInformation(WITH COMPONENTS {
                       ...,
                       otherStrategy  ABSENT
                     })

-- The various parameters have the meanings as defined below:
-- a)	noRefresh indicates that there have been no changes to the shadowed information from the 
-- 	previous instance to the present. This may be used where an IN-UpdateShadow operation 
-- 	must be supplied at a certain interval defined in the shadowing agreement (updateMode), but 
--	no modification has actually occurred.
-- b)	total provides a new instance of the shadowed information. The incremental strategy should 
-- 	be preferably used because it saves signalling.
-- c)	incremental provides, instead of a complete replacement of the shadowed information, only 
-- 	the changes which have occurred to that shadowed information between lastUpdate in the 
-- 	most recent IN-CoordinateShadowUpdate (or IN-RequestShadowUpdate) request and 
-- 	updateTime in the current IN-UpdateShadow request (or IN-RequestShadowUpdate 
-- 	response).
-- d)	otherStrategy provides the ability to send updates by mechanisms outside the scope of the 
--	Directory Specification. For IN CS-4, either a total or incremental strategy should be used.
-- 	Should the request succeed, a result will be returned, although no information will be 
--	conveyd with it. Should the request fail, a shadowError shall be reported. Circumstances
-- 	under which the particular shadow problems will be returned are defined in X.525 Section 
-- 	11.3.3.
in-RequestShadowUpdate OPERATION ::= {
  ARGUMENT  IN-RequestShadowUpdateArgument
  RESULT    IN-RequestShadowUpdateResult
  ERRORS    {shadowError}
  CODE      id-opcode-requestShadowUpdate
}

-- An IN-RequestShadowUpdate operation is used by the shadow consumer to request updates from the 
-- shadow supplier. 
IN-RequestShadowUpdateArgument ::=
  RequestShadowUpdateArgument
    (WITH COMPONENTS {
       ...,
       toBeProtected  (WITH COMPONENTS {
                         ...,
                         requestedStrategy  (standard:incremental |
                                             standard:total)
                       })
     })

IN-RequestShadowUpdateResult ::=
  RequestShadowUpdateResult(WITH COMPONENTS {
                              ...,
                              null  PRESENT
                            })

-- The various parameters have the meanings as defined below:
-- a)	The agreementID identifies the shadowing agreement.
-- b)	The lastUpdate argument is the time provided by the shadow supplier in the most recent 
--	successful update. This argument may only be omitted in the first instance of either a 
--	IN-CoordinateShadowUpdate or IN-RequestShadowUpdate operation for a particular 
--	shadowing agreement.
-- c)	The requestedStrategy argument identifies the type of update being requested by the shadow 
--	consumer. The shadow consumer may request either an incremental or a total update from 
--	the shadow supplier.
-- d)	The securityParameters argument is defined in 7.10 of ITU-T Rec. X.511 | ISO/IEC 9594-3.
-- IN X.500 DSP definition
IN-ChainingArguments ::=
  ChainingArguments
    (WITH COMPONENTS {
       ...,
       aliasedRDNs  ABSENT,
       info         ABSENT,
       timeLimit    ABSENT
     })

-- The IN-ChainingArguments are present in each chained operation, to convey to a DSA the 
-- information needed to successfully perform its part of the overall task:
IN-ChainingResults ::=
  ChainingResults
    (WITH COMPONENTS {
       ...,
       info             ABSENT,
       crossReferences  ABSENT
     })

-- The ChainingResults are present in the result of each operation and provide feedback to 
-- the DSA which invoked the operation.
IN-ReferenceType ::=
  ReferenceType
    (superior | subordinate | nonSpecificSubordinate | supplier | master |
     immediateSuperior | self)

-- A ReferenceType value indicates one of the various kinds of reference defined in ITU-T 
-- Rec. X.501 | ISO/IEC 9594-2.
-- Value (3)(cross reference) is not applicable for IN CS-4 as direct references are assumed.
IN-AccessPoint ::=
  AccessPoint(WITH COMPONENTS {
                ...,
                protocolInformation  ABSENT
              })

-- An AccessPoint value identifies a particular point at which access to the Directory, specifically to a
-- DSA, can occur. The access point has a Name, that of the DSA concerned,
-- and a PresentationAddress,
-- to be used in SS7 signalling to that DSA.
-- The address contains the network address of the DSA in the SS7.
IN-MasterOrShadowAccessPoint ::=
  MasterOrShadowAccessPoint(WITH COMPONENTS {
                              ...,
                              protocolInformation  ABSENT
                            })

-- A MasterOrShadowAccessPoint value identifies an access point to the Directory. 
-- The category, either master or shadow, of the access point is dependent upon whether it points to a 
-- naming context or commonly useable replicated area.
IN-MasterAndShadowAccessPoints ::=
  MasterOrShadowAccessPoint

-- A MasterAndShadowAccessPoints value identifies a set of access points to the Directory, i.e., a set of 
-- related DSAs. These access points share the property that each refers to a DSA holding entry 
-- information from a common naming context (or a common set of naming contexts mastered in one 
-- DSA when the value is a value of the nonSpecificKnowledge attribute. 
-- A MasterAndShadowAccessPoints value indicates the category of each AccessPoint value it contains. 
-- The access point of the master DSA of the naming context need not be included in the set.
-- An AccessPointInformation value identifies one or more access points to the Directory.
IN-AccessPointInformation ::=
  AccessPointInformation(WITH COMPONENTS {
                           ...,
                           protocolInformation  ABSENT
                         })

IN-ContinuationReference ::=
  ContinuationReference
    (WITH COMPONENTS {
       ...,
       aliasedRDNs    ABSENT,
       rdnsResolved   ABSENT,
       referenceType  (IN-ReferenceType),
       accessPoints   (SET OF IN-AccessPoint)
     })

-- A ContinuationReference describes how the performance of all or part of an operation can be 
-- continued at a different DSA or DSAs. It is typically returned as a referral when the DSA involved is 
-- unable or unwilling to propagate the request itself.
-- The various components have the meanings as defined below:
-- a)	The targetObject name indicates the name which is proposed to be used in continuing the 
-- 	operation. This might be different from the targetObject name received on the incoming request
-- 	if, for example, an alias has been dereferenced, or the base object in a search has been located.
-- b)	The aliasedRDNs component indicates how many (if any) of the RDNs in the target object 
--	name have been produced by dereferencing an alias. Since alias entries in IN are just a 
--	means to provide an alternative name for an object and therefore should be dereferenced 
--	when needed, there is no need for this indicator.
-- c)	The operationProgress indicates the amount of name resolution which has been achieved, and
-- 	which will govern the further performance of the operation by the DSAs named, should the 
--	DSA or DUA receiving the ContinuationReference wish to follow it up.
-- d)	The rdnsResolved component value (which need only be present if some of the RDNs in the 
--	name have not been the subject of full name resolution, but have been assumed to be correct 
--	from a cross reference) indicates how many RDNs have actually been resolved, using internal 
--	references only. Since direct knowledge references are assumed, this parameter is deemed not
-- 	applicable for IN CS-4.
-- e)	The referenceType component indicates what type of knowledge was used in generating this 
--	continuation.
-- f)	The accessPoints component indicates the access points which are to be contacted to achieve 
-- 	this continuation. Only where non-specific subordinate references are involved can there be 
-- 	more than one AccessPointInformation item.
-- g)	The entryOnly component is set to TRUE if the original operation was a search, with the 
-- 	subset argument set to oneLevel, and an alias entry was encountered as an immediate 
-- 	subordinate of the baseObject. The DSA which successfully performs name resolution on the 
--	targetObject name, shall perform object evaluation 
--
-- on only the named entry. Since alias 
--	entries in IN are just a means to provide an alternative name for an object and therefore 
--	should be dereferenced when needed, there is no need for this indicator.
-- h)	The exclusions component identifies a set of subordinate naming contexts that should not be 
--	explored by the receiving DSA.
-- i)	The returnToDUA element is optionally supplied when the DSA creating the continuation 
-- 	reference wishes to indicate that it is unwilling to return information via an intermediate DSA 
-- 	(e.g., for security reasons), and wishes to indicate that information may be directly available 
-- 	via an operation over DAP between the originating DUA and the DSA. When returnToDUA is 
-- 	set to TRUE, referenceType may be set to self. This element may be used in IN for support of 
-- 	the shadowing agreement established between network operators (e.g., SDFv to SDFh Modify 
--	may fail based upon access control restrictions).
-- j)	The nameResolveOnMaster element is optionally supplied when the DSA creating the 
-- 	continuation reference has encountered NSSRs. Since direct knowledge references are 
-- 	assumed, this parameter is deemed not applicable for IN CS-4.
in-DSABind OPERATION ::=
  in-DirectoryBind

-- An IN-DSABind operation is used to begin of a period of cooperation between two DSAs providing 
-- the Directory service.
-- A DSA, having received an operation from a DUA, may elect to construct a chained form of that 
-- operation to propagate to another DSA. For IN CS-4 a DSA, having received a chained form of an 
-- operation, must either process the operation or if the originating DSA is in another network, chain it 
-- to another DSA within the same network as the receiving DSA. The DSA invoking a chained form of 
-- an operation may optionally sign the argument of the operation; the DSA performing the operation, 
--if so requested, may sign the result of the operation.
-- The chained form of an operation is specified using the parameterized type IN-chained {}.
in-Chained{OPERATION:operation} OPERATION ::= {
  ARGUMENT OPTIONALLY-PROTECTED
    {SET {in-chainedArgument  IN-ChainingArguments,
          argument            [0]  operation.&ArgumentType},
     dirqop.&dspChainedOp-QOP}
  RESULT OPTIONALLY-PROTECTED
    {SET {in-chainedResult  IN-ChainingResults,
          result            [0]  operation.&ResultType},
     dirqop.&dspChainedOp-QOP}
  ERRORS
    {operation.&Errors EXCEPT (referral | in-DSAReferral)}
  CODE                           operation.&operationCode
}

chainedExecute OPERATION ::= in-Chained{in-Execute}

in-ChainedSearch OPERATION ::= in-Chained{in-Search}

in-ChainedAddEntry OPERATION ::= in-Chained{in-AddEntry}

in-ChainedRemoveEntry OPERATION ::= in-Chained{in-RemoveEntry}

in-ChainedModifyEntry OPERATION ::= in-Chained{in-ModifyEntry}

-- Errors in DSP
in-DSAReferral ERROR ::= dsaReferral

-- the following constraint should b applied to the error parameter
-- (WITH COMPONENTS{
--	...,
--	reference	(IN-ContinuationReference),
--	contextPrefix	ABSENT})
-- The IN-DSAReferral error is generated by the DSA when, for whatever reason, it doesn't wish to 
-- continue performing an operation by chaining the operation to another DSA. For this CS, DSAs may 
-- not chain operations incoming from another DSA unless the DSA is in another network.
-- The various parameter have the meanings as described below:
-- a) The IN-ContinueReference contains the information needed by the invoker to propagate
-- an appropriate further request, perhaps to another DSA.
-- b) If the returnCrossRefs component of the ChainingArguments for this operation had the value
-- TRUE, and the referral is being based upon a subordinate or cross-reference, then the contextPrefix
-- parameter may optionnally be included. The administrative authority of any DSA will decide which
-- knowledge references, if any, can be returned in this manner (the others, for example, may be
-- confidential to that DSA). Since direct knowledge references are assumed for IN-CS3, this parameter
-- is not applicable.
-- IN DISP/DSP common Operation definition
-- inUnbind  OPERATION 
-- This operation is described in Q.1248.1.
-- The INUnbind operation replaces the X.525 dSAShadowUnbind operation and the X.518 dSAUnbind 
-- operation to provide class 4 operation behaviour for unbind procedures.
-- This operation is also used to unbind the TFCBind.
-- trafficFlowControl OPERATION
-- This operation is described in Q.1248.4.
-- tfcBind OPERATION
-- This operation is described in Q.1248.4.
END
-- Generated by Asnp, the ASN.1 pretty-printer of France Telecom R&D