Klim-spec02-Format Data Mail & XML-V3!1!05!08!2014

KLIM Mailing standards SPEC.02

Summary This document describes the mail and the XML file sent by KLIM-CICC to the

concerned members

Target KLIM-CICC members

Version V3.1

Date 05/08/2014

Status Draft Validation Final

Creation

Author Raf Van den Bosch

Date 08/05/2012

File location (ELIA ... KLIM-CICC)/Application-Toepassing/030-Manuals & procedures/040 Standard Mailing/klim-spec02-format data mail & xml-V...doc

Approval

Version Date Name

History of revisions

Version Date Author Summary of changes

V1.1 06/05/2013 Philippe Vanden Eynde New code lists

V1.2 07/11/2013 Philippe Vanden Eynde Reference to doc with code lists (SPEC.03)

V3.0 23/07/2014 Raf Van den Bosch Modifications for KPL-integration

V3.1 05/08/2014 Raf Van den Bosch Additions to the specs

KLIM Mailing Standards Page 2 of 48

111 CCCooonnnttteeennnttt

1 Content .................................................................................................................................... 2 2 Introduction .............................................................................................................................. 4

2.1 Author/Date ...................................................................................................................... 4 2.2 Referred documents ......................................................................................................... 4 2.3 How this document is organized ....................................................................................... 4 2.4 General note on the use of languages .............................................................................. 4 2.5 General note on authentication for the KLIM website ........................................................ 4 2.6 General note on the charsets and encoding used ............................................................. 4

3 The standard request mail ....................................................................................................... 5 3.1.1 Example mail KLIM request ....................................................................................... 5 3.1.2 Example mail KLIP request ........................................................................................ 6

3.2 The 2 main http-links (html-link and xml-link) .................................................................... 7 3.2.1 Where are these links in the mail ? ............................................................................ 7 3.2.2 General structure of these 2 links .............................................................................. 9 3.2.3 Detailed Analysis of the html-link ............................................................................... 9 3.2.4 Detailed Analysis of the xml link ............................................................................... 12

3.3 The confirmation link ....................................................................................................... 13 3.3.1 General description .................................................................................................. 13 3.3.2 How does the confirmation link work ? ..................................................................... 15 3.3.3 Structure of this link ................................................................................................. 18 3.3.4 Real-life example ..................................................................................................... 19

3.4 Attached file link .............................................................................................................. 19 3.4.1 Where is this link in the mail ? .................................................................................. 19 3.4.2 Structure of this link ................................................................................................. 20 3.4.3 Important remark concerning KLIP requests ............................................................ 21 3.4.4 Xml also in attachment ............................................................................................. 21

3.5 What do the coordinates mean in the html mail? ............................................................. 21 3.5.1 Example 1 ............................................................................................................... 22 3.5.2 Example 2 ................................................................................................................ 22

4 The xml in the standard request mail (3) and in the recall mails (6) .................................... 23 4.1 xsd .................................................................................................................................. 23 4.2 Real-life examples .......................................................................................................... 23 4.3 Detailed fields explanation of the tag REQUEST ........................................................... 23

4.3.1 VERSION (REQUIRED) .......................................................................................... 23 4.3.2 SEQREQ (REQUIRED) ........................................................................................... 24 4.3.3 CODLANG (REQUIRED) ......................................................................................... 24 4.3.4 REF (REQUIRED) ................................................................................................... 24 4.3.5 TYPREQ (REQUIRED) ............................................................................................ 24 4.3.6 TYPWORK (REQUIRED BUT BLANK POSSIBLE) ................................................. 24 4.3.7 WORKMETH (REQUIRED BUT BLANK POSSIBLE) .............................................. 26 4.3.8 DESCR (OPTIONAL) ............................................................................................... 26 4.3.9 DATCRE (REQUIRED) ............................................................................................ 26 4.3.10 DATSTART (REQUIRED) ........................................................................................ 26 4.3.11 DATEND (REQUIRED BUT BLANK POSSIBLE) ..................................................... 26 4.3.12 LOC (REQUIRED) ................................................................................................... 26 4.3.13 MUNICIPALITY (REQUIRED) .................................................................................. 27 4.3.14 CONFIRMATIONLINK (REQUIRED) ....................................................................... 27


4.3.15 ATTACHMENTLINK (OPTIONAL) ........................................................................... 27 4.3.16 IMAGELINK (REQUIRED) ....................................................................................... 28 4.3.17 GEOMETRY (REQUIRED) ...................................................................................... 29 4.3.18 ACTOR (REQUIRED) .............................................................................................. 29 4.3.19 INTERSECTION (OPTIONAL) ................................................................................. 29 4.3.20 RECIPIENT (OPTIONAL) ........................................................................................ 29 4.3.21 HASH (REQUIRED) ................................................................................................ 29

4.4 Detailed fields explanation of the tag ACTOR................................................................ 29 4.4.1 SEQACT (REQUIRED) ............................................................................................ 29 4.4.2 USERID (REQUIRED BUT BLANK POSSIBLE) ...................................................... 29 4.4.3 COMPANY (OPTIONAL) ......................................................................................... 30 4.4.4 KEYPERSON (REQUIRED) .................................................................................... 30 4.4.5 EMAIL (REQUIRED) ................................................................................................ 30 4.4.6 STREET (REQUIRED) ............................................................................................ 30 4.4.7 HOUSENR (OPTIONAL) ......................................................................................... 30 4.4.8 ZIPCODE (REQUIRED) ........................................................................................... 30 4.4.9 COUNTRYCODE (REQUIRED) ............................................................................... 30 4.4.10 CITY (REQUIRED) .................................................................................................. 30 4.4.11 TELNR (REQUIRED) ............................................................................................... 30 4.4.12 FAXNR (OPTIONAL) ............................................................................................... 31 4.4.13 KEYPERSON2 (OPTIONAL) ................................................................................... 31 4.4.14 EMAIL2 (REQUIRED) .............................................................................................. 31 4.4.15 TELNR2 (OPTIONAL).............................................................................................. 31 4.4.16 TYPACT (REQUIRED) ............................................................................................ 32

4.5 Detailed fields explanation of the tag RECIPIENT ......................................................... 32 4.5.1 TPIID (REQUIRED) ................................................................................................. 32 4.5.2 OWNERID (REQUIRED) ......................................................................................... 32

5 Images in the standard request mail ...................................................................................... 33 5.1 Clients demand .............................................................................................................. 33

5.1.1 Uniqueness .............................................................................................................. 33 5.1.2 Max 40 char ............................................................................................................. 33

5.2 Implemented restrictions ................................................................................................. 33 5.2.1 Uniqueness .............................................................................................................. 33 5.2.2 Max 24 char (not regarding the extension) ............................................................... 33 5.2.3 Real-life examples ................................................................................................... 33

5.3 Image extension ............................................................................................................. 34 6 The recall mails ...................................................................................................................... 35

6.1 Example of the first recall ................................................................................................ 35 6.2 Example of the second recall .......................................................................................... 36 6.3 Example of the third recall .............................................................................................. 38 6.4 Link to the original mail ................................................................................................... 39

6.4.1 First recall ................................................................................................................ 39 6.4.2 Second recall ........................................................................................................... 41 6.4.3 Third recall ............................................................................................................... 42

6.5 Confirmation link ............................................................................................................. 43 6.5.1 First recall ................................................................................................................ 43 6.5.2 Second recall ........................................................................................................... 45 6.5.3 Third recall ............................................................................................................... 46

6.6 Can the xml be obtained via the recall mail ? .................................................................. 47 7 How to distinguish the recall mails (6) from the standard request mail (3)? ........................ 48


222 IIInnntttrrroooddduuuccctttiiiooonnn

2.1 Author/Date

Raf Van den Bosch 05/08/2014

2.2 Referred documents

[1] KlimRequest.xsd [...] See the files mentioned in 4.2. KLIM-CICC SPEC.02 Code lists

2.3 How this document is organized This document contains information on the mails that are generated when

a user introduces a request on the KLIM website a user introduces a request on the KLIP website. This KLIP request is automatically

forwarded to the KLIM website, which generates the necessary mails.

There are 2 types of standard emails: The email sent to the KLIM or KLIP user who created the request. This email is always

sent. This mail is further in this document referred as the usercopy. The email sent to 1 or more concerned pipeline or cable-network manager(s).

The only 2 differences between these 2 emails are that the usercopy doesnt contain: a confirmation link (see also 4.3.14). recipient information (see also 4.3.20 and 4.5).

There is also a recall mail, discussed in 3.3 and 6.

2.4 General note on the use of languages Emails generated by a request on the KLIM website can be in French, Dutch or German. The user has the choice between these three languages.

Emails generated by a request on the KLIP website are always in Dutch.

2.5 General note on authentication for the KLIM website

None of the links described in this document (see 3.2, 3.3, 3.4, 6.4 and 6.5) requires authentication.

2.6 General note on the charsets and encoding used The charset of the mails is utf-8. The charset of the html headers is also utf-8. The encoding of the xml is utf-8.


333 TTThhheee ssstttaaannndddaaarrrddd rrreeeqqquuueeesssttt mmmaaaiiilll 3.1.1 Example mail KLIM request A KLIM request is generated when a user introduces a request on the KLIM website.

(Note: the KLIM requests can also appear in Dutch or in German).


3.1.2 Example mail KLIP request A KLIP request is generated when a user introduces a request on the KLIP website. KLIP communicates this request to KLIM, and thus a KLIM request is generated with a KLIP identifier. The KLIP identifier can be easily recognized because the id always starts with KLIP-PA-.

(Note: the KLIP request is always in Dutch).


3.2 The 2 main http-links (html-link and xml-link) The 2 main links in a standard KLIM email, that are always present, are:

Link to html form: allows to visualize the email in a browser. The html form contains the same information as the mail.

Link to xml form: contains computer-formatted version of the mail. This can be used by softwares (see 4).

3.2.1 Where are these links in the mail ? They can always be found in the top zone of the mail, as indicated by the red circles here below:


3.2.2 General structure of these 2 links The link has the following form: https://www.klim-cicc.be/klimnl/displayFile.jsp? & ID=... & ID2=... & ID3=... & ID4=... & TYPE=...

https://www.klim-cicc.be/klimnl/displayFile.jsp? : this is the basic url for all KLIM documents in dutch (*1).

ID=... & ID2=... : these 2 IDs are necessary to retrieve one of the 2 documents (=either the html or the xml).

ID3=... & ID4=... : these 2 IDs are necessary to retrieve the other one of the 2 documents (=either the html or the xml). Note that it is just an information provided by the KLIM application for third-party softwares: as such it has no meaning for the KLIM-application.

TYPE=... : this indicates the content of the retrieved document for ID and ID2. Note that it is just an information provided by the KLIM application for third-party softwares: as such it has no meaning for the KLIM-application.

So, briefly speaking, we can conclude that the only real parameters for the KLIM-application are ID and ID2. The other parameters are only information for third-party softwares, that can be exploited as indicated here below (see 3.2.3 and 3.2.4).

(*1: for french the basic url is: https://www.klim-cicc.be/klimfr/displayFile.jsp? , for german the basic url is: https://www.klim-cicc.be/klimde/displayFile.jsp? ) 3.2.3 Detailed Analysis of the html-link The html link is indicated by the red circle:


Example :

dutch: https://www.klim-cicc.be/klimnl/displayFile.jsp?ID=123&ID2=456&ID3=001&ID4=002&TYPE=HTML

french: https://www.klim-cicc.be/klimfr/displayFile.jsp?ID=123&ID2=456&ID3=001&ID4=002&TYPE=HTML

german: https://www.klim-cicc.be/klimde/displayFile.jsp?ID=123&ID2=456&ID3=001&ID4=002&TYPE=HTML

This link will load the html page. However, a thrid party software can derive from this link the link that retrieves the xml page: in that case, the value of ID must be replaced by the value of ID3, and the value of ID2 must be replaced by the value of ID4.

So, for the above example, this will retrieve the xml page (note that the parameter TYPE is omitted):

dutch: https://www.klim-cicc.be/klimnl/displayFile.jsp?ID=001&ID2=002 french: https://www.klim-cicc.be/klimfr/displayFile.jsp?ID=001&ID2=002 german: https://www.klim-cicc.be/klimde/displayFile.jsp?ID=001&ID2=002


3.2.4 Detailed Analysis of the xml link The xml link is indicated by the red circle:


Example :

dutch : https://www.klim-cicc.be/klimnl/displayFile.jsp?ID=001&ID2=002&ID3=123&ID4=456&TYPE=XML

french : https://www.klim-cicc.be/klimfr/displayFile.jsp?ID=001&ID2=002&ID3=123&ID4=456&TYPE=XML

german: https://www.klim-cicc.be/klimde/displayFile.jsp?ID=001&ID2=002&ID3=123&ID4=456&TYPE=XML

This link will load the xml page. However, a third party software can derive from this link the link that retrieves the html page: in that case, the value of ID must be replaced by the value of ID3, and the value of ID2 must be replaced by the value of ID4.

So, for the above example, this will retrieve the html page (note that the parameter TYPE is omitted):

dutch: http://www.klim-cicc.be/klimnl/displayFile?ID=123&ID2=456 french: http://www.klim-cicc.be/klimfr/displayFile?ID=123&ID2=456 german: https://www.klim-cicc.be/klimde/displayFile.jsp?ID=123&ID2=456

3.3 The confirmation link

3.3.1 General description This link is only present in the mails that are sent to the concerned pipeline or cable-network managers. So, it is never present in the usercopy.

The confirmation link is indicated by the red circle:


3.3.2 How does the confirmation link work ? The pipeline or cable-network manager who receives the mail, must confirm the email, by clicking on the confirmation link.

In response, KLIM shows a HTML page that contains the message (KLIMCONFIRMATIONCODE=SUCCESS). So, if the HTML page contains this message, you can be sure that the confirmation has succeeded.

The pipeline or cable-network manager has 3 complete days to confirm the email. After that, some recalls or reminders are sent. These recall-mails are further explained in 6.


3.3.2.1 French example Click on the link in the red circle:

The result must be:


3.3.2.2 Dutch example Click on the link in the red circle:

The result must be:


3.3.2.3 German example Click on the link in the red circle:

The result must be:

3.3.3 Structure of this link The link has the following form: recall/index.jsp?&LG=fr&SEQEMAIL=475105 https://www.klim-cicc.be/recall/index.jsp? & LG=... & SEQEMAIL=...

https://www.klim-cicc.be/recall/index.jsp? : this is the basic url for Dutch as well as for French and for German.

LG=... : Indicates the language of the original klim request. (LG=fr means French, LG=nl means Dutch, LG=de means German).


SEQEMAIL=... : the value of this parameter contains the unique database id of the concerned email. (Each email that is sent by KLIM has a unique ID in the database).

3.3.4 Real-life example

3.4 Attached file link The standard request mail can contain a link to an attached document (maximum 1 attached document). 3.4.1 Where is this link in the mail ? French part: the link can be found at the bottom of the email (see red circle), right above the title Gestionnaires CICC concerns par lannonce.

Dutch part: the link can be found at the bottom of the email (see red circle), right above the title Installatie-eigenaars betrokken bij de melding.


German part: the link can be found at the bottom of the email (see red circle), right above the title Installation Besitzer in der Nachricht beteiligt.

3.4.2 Structure of this link The link has the following form: https://www.klim-cicc.be/klimnl/displayFile.jsp? & ID=... & ID2=...



ID=... & ID2=... : these 2 IDs are necessary to retrieve the attached document

(*1 in french the basic url is : https://www.klim-cicc.be/klimfr/displayFile.jsp? , in german the basic url is: https://www.klim-cicc.be/klimde/displayFile.jsp? ) 3.4.3 Important remark concerning KLIP requests Requests coming from KLIP never contain any attachment.

3.4.4 Xml also in attachment The xml which can be obtained via the link in .3.2.4 is also attached to the standard request mail.

3.5 What do the coordinates mean in the html mail? Question: what does the coordinates in the red rectangle mean? Answer: its the coordinates of some random point that is guaranteed to be situated on the polygon that represents the request.


3.5.1 Example 1

3.5.2 Example 2


444 TTThhheee xxxmmmlll iiinnn ttthhheee ssstttaaannndddaaarrrddd rrreeeqqquuueeesssttt mmmaaaiiilll (((333))) aaannnddd iiinnn ttthhheee rrreeecccaaallllll mmmaaaiiilllsss (((666))) 4.1 xsd

The xml content is restricted by doc [1].

4.2 Real-life examples

01_KlimRequest_KLIP_no_intersections.xml 02_KlimRequest_KLIP_1_intersection.xml 03_KlimRequest_KLIP_actor_housenr_is_null.xml 04_KlimRequest_KLIM_no_intersections.xml 05_KlimRequest_KLIM_2_intersections.xml 06_KlimRequest_KLIM_request_typwork_workmeth_is_blanc.xml 07_KlimRequest_KLIM_request_datend_is_blanc.xml 08_KlimRequest_KLIM_request_descr_is_null.xml 09_KlimRequest_KLIM_actor_faxnr_is_null.xml 10_KlimRequest_KLIM_actor_company_is_null.xml

All of these examples are validated against doc [1] via http://www.corefiling.com/opensource/schemaValidate.html .

4.3 Detailed fields explanation of the tag REQUEST Note: There are 2 kinds of requests : a KLIM request and a KLIP request. In the following chapters, if a difference exists between the treatment of a KLIM request and the treatment of a KLIP request, then this is indicated by using 2 subtitles CASE KLIM and CASE KLIP. If these subtitles are not present, then the KLIM requests and the KLIP requests are treated equally for the concerned tag or subtag.

4.3.1 VERSION (REQUIRED) This indicates the version of the file KlimRequest.xsd ( doc [1] ), to which the XML corresponds. Off course, this field doesnt change often: It only changes when the XML structure of KLIM changes, which is always communicated by KLIM/CICC to every member before the actual changes take place.

The format of this field is a fixed String (KLIM_CICC_V) followed by the datetime (YYYYMMDD_HHMI) which indicates the moment on which the file KlimRequest.xsd ( doc [1] ) is generated.

Full Format : KLIM_CICC_VYYYYMMDD_HHMI.

The version which corresponds to the Mailing Standards described in this document is:

(so the file KlimRequest.xsd ( doc [1] ) is generated on 10/07/2014 at 14:00h).

KLIM_CICC_V20140710_1400


4.3.2 SEQREQ (REQUIRED) This is the unique identifier of the Request.

4.3.2.1 CASE KLIM When the request is introduced in the KLIM interface, the unique identifier is a number. This number increases sequentially.

e.g.:

907001

4.3.2.2 CASE KLIP When the request is introduced in the KLIP interface, the unique identifier is String, which has following format: KLIP-PA- + number. The number increases sequentially.

e.g.: KLIP-PA-0000300400

4.3.3 CODLANG (REQUIRED) Possible values (exhaustive list) :

FR NL DE EN (*1)

(*1 : not used today) 4.3.4 REF (REQUIRED) This is some free text the user can introduce. The user has the possibility to give the request a certain name or reference.

4.3.5 TYPREQ (REQUIRED) The content of this tag describes the type of request. This content can be in French, Dutch or German. So in order to uniquely identify the type of request, we added an attribute id.

e.g.: Werfmelding

The possible values of the attribute id can be found in document KLIM_CICC / SPEC.03 Code lists.

4.3.6 TYPWORK (REQUIRED BUT BLANK POSSIBLE) The content of this tag describes the type of work. This content can be in French, Dutch or German. So in order to uniquely identify the type of request, we added an attribute id.

e.g.:


Aanleg nutsleidingen


Note : When the id = -1, there is no value, which means there is no type of work. This is the case when the field TYPREQ.id = 3 (see 4.3.4).


4.3.7 WORKMETH (REQUIRED BUT BLANK POSSIBLE) The content of this tag describes the type of method. This content can be in French, Dutch or German. So in order to uniquely identify the type of request, we added an attribute id.

e.g.: Mechanisch zonder boring/persing


Note: When the id = -1, there is no value, which means there is no type of work. This is the case when the field TYPREQ.id = 3 (see 4.3.4). 4.3.8 DESCR (OPTIONAL) Description

4.3.9 DATCRE (REQUIRED) Date the announcement was created.

FORMAT: DD/MM/YYYY Example: 01/01/2012

4.3.10 DATSTART (REQUIRED) Startdate of the work.


4.3.11 DATEND (REQUIRED BUT BLANK POSSIBLE) Enddate of the work.


Note : DATEND can be or blank

4.3.12 LOC (REQUIRED) The localization of the work, as encoded by the user.

(This is in fact redundant information, because the localization is visible on the map image. However, the goal of this required field is to have a way to doublecheck the intentions of the requestor.)

Examples (coming from real requests):


Example 1: Spa, av. Marie-Henriette 15

Example 2: Kennedylaan Gent

Example 3: Malle - Azalealaan 3

Example 4: dilbeek herdebeekstraat

4.3.13 MUNICIPALITY (REQUIRED) The localization of the work, as calculated by the KLIM/CICC software. The KLIM/CICC software calculates the municipality in which the request is situated.

If the request is big and it is situated in several municipalities at the same time, then the KLIM/CICC software chooses the municipality in which the request is mainly situated. The KLIM/CICC software executes a spatial analysis to obtain this result.

Example: gent

4.3.14 CONFIRMATIONLINK (REQUIRED) See 3.3.

4.3.15 ATTACHMENTLINK (OPTIONAL) See 3.4.


4.3.16 IMAGELINK (REQUIRED) The link has the following form: https://www.klim-cicc.be/klimnl/displayFile.jsp? & ID=... & ID2=...


ID=... & ID2=... : these 2 IDs are necessary to retrieve the image

(*1 in french the basic url is : https://www.klim-cicc.be/klimfr/displayFile.jsp? , for german the basic url is: https://www.klim-cicc.be/klimde/displayFile.jsp? )

This link retrieves thus the image that situates the KLIM request on map (see green arrow):


4.3.17 GEOMETRY (REQUIRED) The geometric representation of the request.

It corresponds to following restrictions: It is a WKT geometry. (See OGC and ISO definitions of WKT). The coordinate system is Lambert 72.

4.3.18 ACTOR (REQUIRED) The person or legal instance that made the request, further referred as the requestor.

4.3.19 INTERSECTION (OPTIONAL) KLIM internal use only.

4.3.20 RECIPIENT (OPTIONAL) KLIM identification of the pipeline or cable-network manager who receives the XML.

This field is optional because in case of the XML in the usercopy, this information is not applicable, since the usercopy is not sent to a pipeline or cable-network manager but to the requestor.

4.3.21 HASH (REQUIRED) KLIM internal use only.

4.4 Detailed fields explanation of the tag ACTOR Note: There are 2 kinds of requests : a KLIM request and a KLIP request. In the following chapters, if a difference exists between the treatment of a KLIM request and the treatment of a KLIP request, then this is indicated by using 2 subtitles CASE KLIM and CASE KLIP. If these subtitles are not present, then the KLIM requests and the KLIP requests are treated equally for the concerned tag or subtag.

Note: An ACTOR (or plan requestor) is linked to 1 main person, and to 1 secondary person. All the fields here below concern the main person, except following 3 fields : KEYPERSON2,EMAIL2 and TELNR2. These 3 fields will be fully exploited in future KLIM extensions.

4.4.1 SEQACT (REQUIRED)

4.4.1.1 CASE KLIM The unique numeric identifier of the requestor.

4.4.1.2 CASE KLIP Always 0 (zero). 4.4.2 USERID (REQUIRED BUT BLANK POSSIBLE)

4.4.2.1 CASE KLIM The KLIM userid of the requestor, i.e. the userid which he uses to login to KLIM.


4.4.2.2 CASE KLIP Always (blank). 4.4.3 COMPANY (OPTIONAL) Name of the company of the requestor (if exists). 4.4.4 KEYPERSON (REQUIRED) Lastname + + firstname of the requestor. (in theory its possible here to have a value of one space ( ) if lastname and firstname are not given, but normally this doesnt happen.

4.4.5 EMAIL (REQUIRED) The email address of the requestor.

4.4.6 STREET (REQUIRED) The street address of the requestor.

4.4.7 HOUSENR (OPTIONAL) The housenumber address of the requestor.

4.4.8 ZIPCODE (REQUIRED) The postal code address of the requestor.

4.4.9 COUNTRYCODE (REQUIRED) The country code of the requestor.

4.4.9.1 CASE KLIM

The possible values of the country code can be found in document KLIM_CICC / SPEC.03 Code lists.

4.4.9.2 CASE KLIP Possible values (non-exhaustive list) :

AF BE BZ DE NL SI

(note: this is a non-exhaustive list. There are no appointments made with KLIP concerning the country code) 4.4.10 CITY (REQUIRED) The city address of the requestor.

4.4.11 TELNR (REQUIRED) The telephone or GSM number of the requestor.


4.4.12 FAXNR (OPTIONAL) The fax number of the requestor.

4.4.13 KEYPERSON2 (OPTIONAL) A second person who is linked to the requestor.

Format is identical to the field KEYPERSON.

4.4.14 EMAIL2 (REQUIRED) Contains the same information as the field EMAIL.

In the future this will become the email address of the second person linked to the requestor. But today its the email address of the main person linked to the requestor, so today it contains exactly the same information as the field EMAIL.

4.4.15 TELNR2 (OPTIONAL) The telephone or GSM number of the second person linked to the requestor.

Format is identical to the field TELNR.


4.4.16 TYPACT (REQUIRED) The content of this tag describes the type of requestor (or user). This content can be in French, Dutch or German. So in order to uniquely identify the type of request, we added an attribute id.

e.g.: architect


4.5 Detailed fields explanation of the tag RECIPIENT Before diving into details, we need to explain how the cables and pipelines are managed in the KLIM-application.

Each cable or pipeline is in fact linked to 3 KLIM entities: Member : The KLIM entity that is an active member of KLIM. Owner : The KLIM entity that legally owns the cable or pipeline. Administrator : The KLIM entity that is responsible of treating KLIM requests that

concern this cable or pipeline. These are the people that treat the KLIM-mails.

4.5.1 TPIID (REQUIRED) KLIM internal Identification number. This field contains the id of the Administrator.

4.5.2 OWNERID (REQUIRED) KLIM internal Identification number. This field contains the id of the owner.

Administrator

Member Owner


555 IIImmmaaagggeeesss iiinnn ttthhheee ssstttaaannndddaaarrrddd rrreeeqqquuueeesssttt mmmaaaiiilll

5.1 Clients demand The name of the image in the mail must comply to following restrictions:

5.1.1 Uniqueness The name must be unique, because some mail-programs have problems when they receive multiple mails with the same image-names. For instance : OutLook.

5.1.2 Max 40 char KLIM has decided that the name of the image may not be longer than 40 characters.

5.2 Implemented restrictions

5.2.1 Uniqueness

The generated filename is constructed like this:

i + currentTime.getMilliseconds() + 4 digits

Where: currentTime.getMilliseconds() : is the current system time expressed by a

number, the system time is expressed as a java.lang.long, which has a max length of 19 characters.

4 digits : For each image generated we add 4 digits at the end of the filename, it concerns a 4-digit counter which starts with 0000 and ends with 9999, and then restarts with 0000.

5.2.2 Max 24 char (not regarding the extension) i = 1 char currentTime.getMilliseconds() = max 19 char 4 digits = 4 char

So, we have a max length of 24 characters.

5.2.3 Real-life examples Example 1: i12910296330040014

Analysis of example 1: i + 1291029633004 + 0014

Example 2: i12910301687070002


Analysis of example 2: i + 1291030168707 + 0002

5.3 Image extension The filename extension can be determined via the MIME Type.

Possible extensions : .jpeg .jpg .png .gif .tif .tiff


666 TTThhheee rrreeecccaaallllll mmmaaaiiilllsss

As indicated in 3.3.2, the pipeline or cable-network manager has 3 complete days to confirm the email. Then, a recall-mechanism starts:

First recall : After 3 complete days, if the email is not confirmed, the KLIM system sends a recall.

Second recall : After 6 complete days, if the email is not confirmed, the KLIM system sends a second recall. This recall is also sent to the contact mail-address of the concerned KLIM member.

Third and last recall: After 9 complete days, if the email is not confirmed, the KLIM system sends a third recall. This recall is also sent to the contact mail-address of the concerned KLIM member. After this third recall no more recalls are sent anymore.

(Note: The recall mails are sent once every day around somewhere between 1AM and 9AM)

6.1 Example of the first recall A request that was originally in French will have a recall mail with the first part in French, the second part in Dutch (*1) and the third part in German (*1):

A request that was originally in Dutch, will have a recall mail with the first part in Dutch, the second part in French (*1) and the third part in German (*1):


A request that was originally in German, will have a recall mail with the first part in German, the second part in French (*1) and the third part in Dutch (*1):

(*1: the content of the French ,the Dutch and the German part is exactly the same)

6.2 Example of the second recall A request that was originally in French will have a recall mail with the first part in French, the second part in Dutch (*1) and the third part in German (*1):



6.3 Example of the third recall A request that was originally in French will have a recall mail with the first part in French, the second part in Dutch (*1) and the third part in German (*1):





6.4 Link to the original mail The links to the original mail are indicated by the red circles, notice that the links are equal for French, Dutch and German part. This is logic, because they refer the same original mail.

This link loads the html form as indicated in 3.2 and 3.2.3.

6.4.1 First recall


6.4.2 Second recall


6.4.3 Third recall


6.5 Confirmation link The confirmation links are indicated by the red circles, notice that the links are equal for French, Dutch and German part. This is logic, because they refer the same original mail.

Clicking a confirmation link has the same effect as indicated in 3.3.2. 6.5.1 First recall


6.5.2 Second recall


6.5.3 Third recall


6.6 Can the xml be obtained via the recall mail ? The xml can also be obtained: take the confirmation link (see 6.5) and adapt it as explained at the end of 3.2.3.


777 HHHooowww tttooo dddiiissstttiiinnnggguuuiiissshhh ttthhheee rrreeecccaaallllll mmmaaaiiilllsss (((666))) fffrrrooommm ttthhheee ssstttaaannndddaaarrrddd rrreeeqqquuueeesssttt mmmaaaiiilll (((333)))???

This can by use of the title of the mail.

For the recall mails, the first word of the mail title is: French version : RAPPEL KLIM Dutch version : HERINNERING German version : ERRINERUNGSNACHRICHT

For the standard request mail, the first word of the mail title is: French version : KLIM-CICC Dutch version : KLIM-CICC German version : KLIM-CICC

Date post:	22-Nov-2015
Category:	Documents
Upload:	nico-van-hoof
View:	32 times
Download:	5 times

Klim-spec02-Format Data Mail & XML-V3!1!05!08!2014

Documents