natgillin/translations-raw huggingface dataset:
Sensitivity Indication gør det muligt for afsenderen at angive, hvor fortrolig en meddelelse efter hans mening er, og om den f.eks. kun bør læses af modtageren.
Enables the originator to indicate his view on the sensitivity of a message, and whether, for example, only the recipient should read it.
Der findes tre niveauer af fortrolighed (foruden standardniveauet):
There are three levels above the default level:
- Personligt.
Personal.
Meddelelsen er sendt til modtageren som enkeltperson uden sammenhæng med den funktion, han udfylder. - Privat.
The message has been sent to the recipient as an individual rather than in his role, for example to John Smith, rather than to the Sales Branch Head.
Kun modtageren bør læse meddelelsen. - Virksomhedsinternt.
Private. Only the recipient should read the message.
Meddelelsen indeholder oplysninger, der skal behandles i overensstemmelse med bestemte virksomhedsprocedurer (f.eks. oplysninger om nye priser).
(iii) Company confidential. The message contains information that should be handled according to company procedures, for example new information about prices.
Dette tjenesteelement gør det muligt at klassificere en meddelelse i forhold til fortrolighed, men garanterer ikke, at modtageren vil efterleve klassifikationen.
Although this service element enables a sensitivity indication to be put on a message, it does not guarantee that the recipient will respect the indication.
Subject Indication gør det muligt for afsenderen over for modtageren at angive meddelelsens emne.
Enables the recipient to indicate the subject of the message to the recipient.
Submission Time Stamp Indication gør det muligt for meddelelsesoverførselssystemet over for såvel sendende som modtagende UA at angive dato og tidspunkt for en meddelelses overgivelse til systemet.
Enables the MTS to indicate to originating and recipient UAs the date and time at which a message was submitted to the MTS.
III SUPPLERENDE TEKNISKE OPLYSNINGER
111.1.9.1988 functional groups
Timed Obsoletìng Indication gør det muligt for brugeren at angive, hvornår tjenesteelementet Obsoleting Indication skal aktiveres.
Anumber of new groups of functions were added to the 1988 version of the X.400 standard: distribution list processing,
ISO-defineret, CCTCT-defineret for G3-faxside, teletexdokument) sammen med indholdsdelen.
1984 interworking, use of directory, secure messaging, conversion, physical delivery.
Hver funktionsgruppe indeholder et antal funktioner, der kort er beskrevet nedenfor:
Each functional group comprises a number of functions as summarized below:
Denne funktionsgruppe gør det muligt for afsenderen at give meddelelsesoverførselssystemet besked om, at en given meddelelse skal sendes til mere end én modtager.
This functional group makes it possible for senders to request that messages submitted to an MTS be transmitted to more than one recipient.
Brugeren angiver navnet på en gruppe (f.eks. EPHOS-projektgruppen) i stedet for navnene på de enkelte gruppemedlemmer.
The sender supplies the name of a group (such as Ephos Project Board) rather than the names of the individuals in the group.
Denne funktionsgruppe gør det muligt for implementeringer, der er baseret på 1988-udgaven at arbejde sammen med implementeringer baseret på 1984-udgaven.
This group of functions makes it possible for an implementation based on the 1988 version of the standard to interwork with those based on the 1984 version.
Basisstandarderne kræver, at alle 1988-baserede UA'er er i stand til arbejde sammen med såvel 1984- som 1988-baserede UA'er. Denne funktionsgruppe skal implementeres, såfremt en 1988-baseret MTA skal kunne udveksle meddelelser med 1984-baserede MTA'er; en situation, der typisk opstår, når en 1988-baseret MTA skal kunne kommunikere med eksisterende ADMD'er.
The base standards require that all 1988-based UAs must be able to work with both 1984 and 1988-based UAs.
X.500-anbefalingerne om katalogtjenester blev offentliggjort i 1988.
The X.500 directory standards were published in 1988.
Kataloget blev udviklet med henblik på at kunne rumme information af betydning for OSI-kom-munikation omfattende MHS, f.eks. adresseoplysninger.
The directory was devised to contain information, such as addressing details, needed for OSI communications including MHS.
Hvis sådan information skal findes i kataloget, er det nødvendigt, at brugerens UA eller MTA kan anvende tjenesteelementerne i denne funktionsgruppe.
If the directory is to be used for finding such information, either the user's UA or MTA should implement this functional group.
Sikker adgangsforvaltning vedrører spørgsmålet om at etablere korrekte forbindelser mellem par af MHS-komponenter, f.eks. mellem UA'er og de tilsvarende MTA'er, hvor det bør sikres, at en given UA har ret til adgang til en given MTA.
Secure access management and administration deals with the problem of establishing authenticated links between pairs of components in the MHS, for example between UAs and their MTAs where it would ensure that a given UAis entitled to access a given MTA.
De fleste af tjenesteelementer i sikker meddelelsesbehandling har at gøre med sikkerhedsfunktioner i UA'er. F.eks. kan det være nyttigt, at en UA er i stand til at kryptografere og dekode meddelelser, samtidig med at den kan anvende enhver slags meddelelsesoverførselssystem.
Most of the secure messaging service elements are concerned with providing security features for UAs.
Der arbejdes inden for EWOS (European Workshop for Open Systems) på at opdele denne funktionsgruppe i forskellige sikkerhedsniveauer. niveauer.
Work is currently under way in the European Workshop for Open Systems (EWOS) to divide this functional group into different levels of security.
Normalt ændrer meddelelsesoverførselssystemer ikke meddelelsernes indhold.
Normally, MTSs do not alter the contents of messages.
Funktionsgruppen Conversion gør det muligt for systemet at konvertere en meddelelses indhold fra én type til en anden, såfremt brugeren ønsker det.
The conversion functional group enables an MTS to convert message content from one type to another if a user requires it.
Acess Units (adgangsenheder)
Access units
Disse enheder gør det muligt at forbinde meddelelseshåndteringssystemer med andre tjenester, f.eks. telex, télétex og fax.
Access units allow MHS to interface with other services such as telex, teletex or facsimile.
Ved hjælp af en adgangsenhed kan en meddelelse f.eks. sendes via et meddelelseshåndteringssystem og modtages på en fax.
Using an access unit, a message could be sent across an MHS and received by a facsimile machine, for example.
Der findes to funktionsgrupper inden for fysisk levering.
There are two functional groups for physical delivery.
Den ene gør det muligt for afsenderen at sende meddelelser i fysisk form, f.eks. ved at trykke dem ud på papir og ekspedere dem i papirkonvolutter.
One allows originators to direct messages to physical mail recipients by printing them on paper and enclosing them in a paper envelope, for example.
Meddelelsen leveres til modtageren af det traditionelle postvæsen.
The message is then passed to a postal system for delivery.
Den anden funktionsgruppe gør det muligt at forbinde en MTA med en særlig funktionskomponent, der kaldes en PDAU (Physical Delivery Access Unit).
The other functional group allows an MTA to interface to a functional component called a physical delivery access unit (PDAU).
PDAU'er er endnu ikke særligt præcist defineret.
PDAUs are not well specified at present.
Meddelelseslagre (MS) er blevet indført for at gøre MHS-konfigurationerne mere fleksible.
Message stores (MS) were introduced to add greater flexibility to MHS configurations.
Lagrene er skudt ind mellem UA'er og MTA'er.
They lie between UAs and their MTAs.
Da UA'er ikke nødvendigvis hele tiden er forbundet med de tilsvarende MTA'er, kan der opstå forsinkelser i meddelelsesoverførselssystemets levering af meddelelser.
Since UAs may not be on-line at all times, MTSs may experience delays in trying to deliver messages.
Indførelsen af meddelelseslagre betyder, at en UA kan få adgang til de meddelelser, der er beregnet til den, på det tidspunkt, hvor det er belejligt, samt at meddelelsesoverførselssystemet ikke behøver opbevare meddelelser i en længere periode. Hvert meddelelseslager er til-
The introduction of a message store means that a UA can access its messages when it is convenient, and that the MTS does not have to hold on to messages for prolonged periods of time.
SUPPLERENDE TEKNISKE OPLYSNINGER knyttet én bruger, dvs. et O/R-navn, og kan ikke anvendes af flere brugere.
Each message store serves only one user, that is one O/R address, and cannot be shared by others.
- Adgangsprotokol for meddelelseslagre {Message Store Access Protocol) P7 (forbindelse mellem en ikke-lokal UA og et meddelelseslager).
The 1988 version of the standard improved the functionality of the PI and P3 protocols and introduced a new protocol: Message store access protocol P7 between a remote UA and an MS (message store).
Nedenfor gennemgås tre forskellige anvendelser, der illustrerer forskellige måder at implementere X.400 på.
Three different applications are presented here in order to suggest some ways in which the X.400 standard might be implemented.
Anbefalingerne er udformet med henblik på at sikre stor fleksibilitet hvad angår de typer af meddelelser, der kan sendes, og især 1988-udgaven åbner mulighed for at kombinere MHS-elementer i en lang række forskellige konfigurationer.
The standard was designed to offer a great deal of flexibility as to the types of messages which can be transmitted, and the 1988 version of the standard in particular allows for a number of different configurations of the elements making up the MHS.
Figur 3.1.1/7: Typisk anvendelse, scenario 1
Figure 3.1.1/7: Typical application of Scenario 1
I den her tænkte situation har virksomhed A en minidatamat med 20 tilsluttede terminaler. Det anvendte programmel er en leverandørspecifik kontorautomationspakke omfattende et elektronisk postsystem.
In this scenario, Company A has a minicomputer with 20 terminals linked to it.
Leverandøren af kontorautomationsprogrammellet har desuden installeret en X.400-gateway.
The computer runs a proprietary office automation package which includes an electronic mail
SUPPLERENDE TEKNISKE OPLYSNINGER
Typical messages sent are texts such as business letters.
Figur 3.1.1/8: Typisk anvendelse, scenario 2
Figure 3.1.1 /8: Typical application of Scenario 2
Alle tre råder over X.400-systemer og har adgang til det offentlige X.400-system (ADMD).
AHthree have X.400 systems and they subscribe to their national X.400 system (ADMD).
Det betyder, at hver virksomhed kun har behov for én forbindelse udadtil.
Setting up links to the national systems means that only one link is required by each company.
Det of fentlige system varetager transporten af meddelelser til de tiltænkte virksomheder (PRMD), hvor meddelelserne overføres til de relevante "postkasser".
The national system will route the messages to the appropriate company (PRMD), which can transfer them to the correct mailbox.
Bruger A
User A
Figur 3.1.1/9: Typisk anvendelse, scenario 3
Figure 3.1.1 /9: Typical application of Scenario 3
Situation er karakteriseret af følgende anvendelsesbehov: Bruger A's PC er forbundet til en mainframe via et lokalnet (LAN).
This scenario is based on the following application requirements: User As personal computer is linked to a mainframe via a LAN.
På PC'en er der installeret en UA, og en mainframe kører MTA 1, og den har adgang til X.500-kataloget.
The personal computer runs a UA and the mainframe runs an MTA and is also linked to the X.500 directory.
Det betyder, at bruger A kan sende en meddelelse til bruger B uden at kende hans fuldstændige adresse, idet der automatisk søges efter de manglende oplysninger i kataloget, før meddelelsen sendes til MTA 2.
In this way, when User A wishes to send a message to User B without knowing full details of his address, the directory is consulted automatically in order to fill in the necessary details. The message can thus be sent to MTA2.
I dette tilfælde kan kun 1988-anbefalingerne anvendes. des.
In this case, only the 1988 version of the standard can be used.
ISO's resultater blev offentliggjort som Draft International Standards, men det blev besluttet ikke at arbejde videre på dem.
These were published as draft international standards, but it was decided not to proceed with their development.
I stedet vedtog CCITT og ISO at samarbejde om udviklingen af 1988-standarder, der skulle åbne mulighed for en lang række funktioner.
Instead both organizations decided to cooperate on the joint development of 1988 standards which would offer a wider range of functions.
Der er udviklet to ENV'er på basis af X.400-anbefalingerne:
Two ENVs based on the X.400 standard have been developed:
- ENV 41201 vedrørende forbindelser mellem PRMD'er. - ENV 41202 vedrørende forbindelser mellem PRMD'er og ADMD'er.
ENV41201 for links between private domains; ENV41202 for linking private domains to administrative domains.
ENV 41201 er baseret på ISO-standarderne, og ENV 41202 på CCITT-anbefalin-gerne.
ENV 41201 is based on the ISO standards and ENV 41202 on the CCITT standards.
De grundlæggende træk i de to ENV'er er i det væsentlige ens, og de fleste X.400-produkter vil være i overensstemmelse med begge.
Most of the basic features of these two ENVs are the same and most X.400 products will conform to both of them.
Der arbejdes for tiden i EWOS på at udvikle yderligere europæiske standarder på basis af 1988-udgaven af X.400.
Work is under way in the European Workshop for Open Systems to develop further European standards based on the 1988 version of X.400.
Tre standarder er under udvikling:
Three standards are being developed:
Disse standarder har endnu ikke opnået ENV-status og er derfor ikke behandlet i denne udgave af EPHOS.
These have not yet reached ENV status and so are not covered in this edition of Ephos.
De vil blive behandlet i en senere udgave, når først de har opnået ENV-status.
They will be dealt with in a future version of Ephos when they have become ENVs.
III.4 ENV 41201-tjenester
Services provided by ENV 41201
Overførsel af meddelelser fra ét PRMD til et andet som beskrevet i denne håndbog er baseret på ENV 41201.
Message transfer from PRMD to PRMD as described in this handbook is based on ENV 41201.
Alle definitioner og krav i ENV 41201 er gældende.
All definitions and requirements of ENV 41201 apply.
Alle indkøbte meddelelseshåndteringssystemer til brug mellem PRMD'er skal derfor være i overensstemmelse med ENV 41201, og samarbejde mellem systemer skal altid ske på basis af ENV 41201.
Therefore, all procured PRMD-to-PRMD MHS systems shall conform to ENV 41201, and interworking shall always be possible on the basis of ENV 41201 compatibilities.
Alle systemer i overensstemmelse med ENV 41201 skal være i stand til sende og modtage IA5-tegnsættet, der svarer til 7—bit ASCII, og skal desuden kunne modtage ISO 6937-tegn (teletex-delen).
All systems conforming to ENV 41201 must be able to originate and receive the IA5 text character set, which is equivalent to ASCII, and must be able to receive the ISO 6937 characters (Teletex subset).
Såfremt et system ikke er i stand til at modtage en bestemt datatype, vil de meddelelser, der anvender denne, blive returneret som nondelivered (ikke-leverede).
If a system is not able to receive a particular body part type, the message containing it will be returned as non-delivered.
Systemerne skal kunne håndtere meddelelser af en størrelse på op til 2 megabyte.
The maximum message size which must be supported is 2 megabytes.
SUPPLERENDE TEKNISKE OPLYSNINGER
SUPPLEMENTARYTECHNICAL INFORMATION
Navngivning og adressering
Naming and addressing
Ifølge ENV 41201 er det et krav, at meddelelseshåndteringssystemer kan generere forskellige elementer til brug i adressefelterne. Standarden specificerer desuden, hvor mange tegn disse felter skal kunne indeholde.
ENV 41201 requires that an MHS system be able to generate certain elements which can be used in the address field and also specifies the number of characters these fields must be able to contain.
Der er imidlertid ikke noget krav om, at samtlige adressefelter skal være anvendt i en given meddelelse, eller om at felternes eventuelle indhold skal være af maksimumlængde.
However, it does not require that the address on every message must contain all of these fields or that an entry in the field must be of maximum length.
F.eks. kan efternavnsfeltet indeholde op til 40 tegn, men efternavne på mindre end 40 tegn accepteres.
For example, the surname field can contain up to 40 characters, but surnames with fewer than 40 characters are acceptable.
Nedenstående tabel viser de obligatoriske adresseelementer samt det antal tegn, de forskellige felter skal kunne indeholde.
The following table lists the required address elements and the number of characters they must be able to support.
16 tegn 16 tegn 64 tegn 32 tegn (Elementet kan højst optræde 4 gange)
16 characters 16 characters 64 characters 32 characters (Max. number of occurrences = 4)
40 tegn 16 tegn 5 tegn
40 characters 16 characters 5 characters
Følgende datatyper er valgmuligheder i ENV 41201 og kan indgå i visse anskaffelser, hvor det er relevant:
The fact that one of these options is not implemented will not prevent interworking on the basis of the common subset of functions being performed by cooperating systems.
Bemærk: Såfremt modtager-UA'en ikke kan håndtere en bestemt datatype i en meddelelse, returnes denne som nondelivered (ikke leveret).
Note: If the receiving UA does not support a given body part type, the message containing it will be returned as non-delivered.
Valgfrie tjenesteelementer
Service element options
Der findes et antal tjenesteelementer, der er valgfrie ifølge ENV 41201, (og som ikke udgør et krav i forbindelse med europæiske offentlige myndigheders indkøb).
There are a number of service elements which are optional in ENV 41201 (and which are not mandatory in procurements by European public administrations).
Desuden kan indkøbere anmode om, at tjenesteelementer, der er obligatoriske for en part (afsender/modtager), også leveres af den anden, hvis dette er af relevans.
In addition, procurers can request that service elements which are mandatory in one role be supported in the other role as well where applicable.
De tjenesteelementer, der kan komme på tale, er vist i den følgende tabel sammen med deres status ifølge ENV 41201:
The service elements which may be requested are shown in the following table along with their mandatory role support status in ENV 41201.
III.5 ENV 41202-Tjenester
Services provided by ENV41202
Overførsel af meddelelser fra et PRMD til et ADMD samt mellem ADMD'er ind byrdes, som beskrevet i denne håndbog, er baseret på ENV 41202.
Message transfer between PRMDs and ADMDs and among ADMDs as described in this handbook is based on ENV 41202.
Alle definitioner og krav i ENV 41202 er gældende.
All definitions and requirements of ENV 41202 apply.
Alle indkøbte meddelelseshåndteringssystemer til brug mellem PRMD'er og ADMD'er eller mellem flere ADMD'er indbyrdes skal derfor være i overensstemmelse med ENV 41202, og samarbejde mellem systemer skal altid ske på basis af ENV 41202.
Therefore, all procured PRMD-to-ADMD or ADMD-to-ADMD MHS systems shall conform to ENV 41202, and interworking shall always be possible on the basis of ENV 41202 compatibilities.
Alle systemer i overensstemmelse med ENV 41202 skal være i stand til sende og modtage IA5-tegnsættet.
All systems conforming to ENV 41202 must be able to originate and receive the IA5 text character set.
ENV 41202 sætter ingen begrænsninger på meddelelsens omfang.
No maximum message size is specified in ENV 41202.
De tjenesteelementer, der ifølge ENV 41202 er obligatoriske i MHS-profilen for overførsel til eller fra ADMD'er, samt de parter (afsender/modtager), der skal understøttes, er nøjagtigt de samme som i ENV 41201.
The required service elements of the PRMD-ADMD/ADMD-ADMD message handling system profile as specified in ENV 41202 and the roles which shall be supported are exactly the same as those required by ENV 41201.
I afsnit III.4 findes en nærmere redegørelse herfor.
See the discussion of service elements in III. 4 for details.
Ifølge ENV 41202 er det et krav, at meddelelseshåndteringssystemer kan generere forskellige elementer til brug i adressefelterne.
ENV 41202 requires that an MHS system be able to generate certain elements which can be used in the address field and also specifies the number of characters these fields must
Nedenstående tabel viser de krævede adresseelementer samt det antal tegn, de forskellige felter skal kunne indeholde.
The following table lists the required address elements and the number of characters they must be able to support.
(Elementet kan højst optræde 4 gange)
16 characters 16 characters 64 characters 32 characters (Max. number of occurrences = 4)
(Elementet kan højst optræde 4 gange)
40 characters 16 characters 5 characters
VALGMULIGHEDER I ENV 41202
Options in ENV 41202
Ifølge ENV 41202 er visse datatyper samt tjenesteelementer generelt eller for enten afsender- eller modtagerparten valgmuligheder, dvs. at den ordregivende myndighed selv skal tage stilling til, hvorvidt de skal indgå i indkøbsaftalen og i givet fald give implementøren besked herom.
ENV 41202 leaves support of certain body part types, support of certain service elements and support of roles for which support is not mandatory in required service elements as options, i.e. the procurer has to decide whether or not to include them in his system, and therefore whether or not to request them from the implementor.
Manglende implementering af en af disse valgmuligheder forhindrer ikke systemet i at arbejde sammen med andre systemer for så vidt angår de funktioner, der understøttes i de berørte systemer.
The fact that one of these options is not implemented will not prevent interworking on the basis of the common subset of functions being performed by cooperating systems.
De datatyper, der findes for ENV 41202-baserede indkøbsspecifikationer, er nøjagtigt de samme som for ENV 41201-baserede indkøbsspecifikationer.
The body part types which the procurer can specify in procurement specifications based on ENV 41202 are exactly the same as those available for procurements based on ENV 41201.
I afsnittet om valgmuligheder i ENV 41201 i III.4 findes en nærmere redegørelse.
See the discussion of options in ENV 41201 in III.4 for details.
Der findes et antal tjenesteelementer, der er valgfrie ifølge ENV 41202, og som ikke udgør et krav i forbindelse med europæiske offentlige myndigheders indkøb.
There are a number of service elements which are optional in ENV 41202 (and which are not mandatory in procurements by European public administrations). They can be
Desuden kan indkøbere anmode om, at tjenesteelementer, der er obligatoriske for en part (afsender/modtager), også leveres af den anden part, hvis dette er af relevans.
In addition, procurers can request that service elements which are mandatory in one role be supported in the other role as well where applicable.
De tjenesteelementer, der kan komme på tale, er vist i nedenstående tabel sammen med deres status ifølge ENV 41202
The service elements which may be requested are shown in the following table along with their mandatory role support status in ENV 41202.
Figur 3.1.1/14: Valgfrie tjenesteelementer i ENV 41202
Figure 3.1.1/14: Optional service elements in ENV 41202
FTAM vil være det rigtige valg, når der ønskes tilvejebragt filbehandlingsfaciliteter (f.eks. overførsel af filindhold eller læsning af filattributter), hvad enten disse faciliteter ønskes anvendt som et selvstændigt værktøj eller som en del af en større programmelpakke.
FTAM will be the choice when the requirement to be fulfilled is the capability to handle files (e.g. transfer file contents or read file attributes) whether this capability is required for use in a dedicated utility or in a filehandling function embedded in another software package.