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 0!0"!#01$
Status %raft Validation &inal
Creation
Author
'af Van den (osch
Date
0"!0!#01#
File location )*LI+ ... KLIM-CICC,!+--lication-Toe-assin.!030-Manuals /
-rocedures!0$0 0tandard Mailin.!1lim-s-ec0#-format data mail / 2ml-
V...doc
Approval
Version Date Name

istory o! revisions
Version Date Author Summary o! changes
V1.1 03!0!#013 4hili--e Vanden *ynde 5e6 code lists
V1.# 07!11!#013 4hili--e Vanden *ynde 'eference to doc 6ith code lists )04*C.03,
V3.0 #3!07!#01$ 'af Van den (osch Modifications for K4L-inte.ration
V3.1 0!0"!#01$ 'af Van den (osch +dditions to the s-ecs




KLIM Mailing Standards Page 2 of 48


1
11 C
CCo
oon
nnt
tte
een
nnt
tt

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



KLIM Mailing Standards Page 3 of 48
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




KLIM Mailing Standards Page 4 of 48

2
22 I
IIn
nnt
ttr
rro
ood
ddu
uuc
cct
tti
iio
oon
nn
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.



KLIM Mailing Standards Page 5 of 48


3
33 T
TTh
hhe
ee s
sst
tta
aan
nnd
dda
aar
rrd
dd r
rre
eeq
qqu
uue
ees
sst
tt m
mma
aai
iil
ll
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).



KLIM Mailing Standards Page 6 of 48

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).



KLIM Mailing Standards Page 7 of 48

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:





KLIM Mailing Standards Page 8 of 48






KLIM Mailing Standards Page 9 of 48

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:



KLIM Mailing Standards Page 10 of 48







KLIM Mailing Standards Page 11 of 48


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






KLIM Mailing Standards Page 12 of 48

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







KLIM Mailing Standards Page 13 of 48


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:



KLIM Mailing Standards Page 14 of 48








KLIM Mailing Standards Page 15 of 48


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.



KLIM Mailing Standards Page 16 of 48

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


The result must be:






KLIM Mailing Standards Page 17 of 48

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



The result must be:







KLIM Mailing Standards Page 18 of 48

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).



KLIM Mailing Standards Page 19 of 48
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.




KLIM Mailing Standards Page 20 of 48


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=...

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



KLIM Mailing Standards Page 21 of 48
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.



KLIM Mailing Standards Page 22 of 48

3.5.1 Example 1

3.5.2 Example 2




KLIM Mailing Standards Page 23 of 48

4
44 T
TTh
hhe
ee x
xxm
mml
ll i
iin
nn t
tth
hhe
ee s
sst
tta
aan
nnd
dda
aar
rrd
dd r
rre
eeq
qqu
uue
ees
sst
tt m
mma
aai
iil
ll (
((
3
33)
)) a
aan
nnd
dd i
iin
nn t
tth
hhe
ee r
rre
eec
cca
aal
lll
ll m
mma
aai
iil
lls
ss (
((
6
66)
))
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



KLIM Mailing Standards Page 24 of 48
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.:

<klim:SEQREQ>907001</klim:SEQREQ>

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.:
<klim:SEQREQ>KLIP-PA-0000300400</klim:SEQREQ>

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.:
<klim:TYPREQ id="4">Werfmelding</klim:TYPREQ>

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.:



KLIM Mailing Standards Page 25 of 48
<klim:TYPWORK id="1">Aanleg nutsleidingen</klim:TYPWORK>

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


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).



KLIM Mailing Standards Page 26 of 48

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.:
<klim:WORKMETH id="2">Mechanisch zonder boring/persing</klim:WORKMETH>

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


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.

FORMAT: DD/MM/YYYY
Example: 01/01/2012
4.3.11 DATEND (REQUIRED BUT BLANK POSSIBLE)
Enddate of the work.

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

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):



KLIM Mailing Standards Page 27 of 48
Example 1:
<klim:LOC>Spa, av. Marie-Henriette 15 </klim:LOC>

Example 2:
<klim:LOC>Kennedylaan Gent </klim:LOC>

Example 3:
<klim:LOC>Malle - Azalealaan 3 </klim:LOC>

Example 4:
<klim:LOC>dilbeek herdebeekstraat </klim:LOC>

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:
<klim:MUNICIPALITY>gent</klim:MUNICIPALITY>
4.3.14 CONFIRMATIONLINK (REQUIRED)
See 3.3.

4.3.15 ATTACHMENTLINK (OPTIONAL)
See 3.4.



KLIM Mailing Standards Page 28 of 48

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

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 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):






KLIM Mailing Standards Page 29 of 48

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.



KLIM Mailing Standards Page 30 of 48
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.



KLIM Mailing Standards Page 31 of 48
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.






KLIM Mailing Standards Page 32 of 48

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.:
<klim:TYPACT id="12">architect</klim:TYPACT>

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

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



KLIM Mailing Standards Page 33 of 48



5
55 I
IIm
mma
aag
gge
ees
ss i
iin
nn t
tth
hhe
ee s
sst
tta
aan
nnd
dda
aar
rrd
dd r
rre
eeq
qqu
uue
ees
sst
tt m
mma
aai
iil
ll

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



KLIM Mailing Standards Page 34 of 48

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







KLIM Mailing Standards Page 35 of 48
6
66 T
TTh
hhe
ee r
rre
eec
cca
aal
lll
ll m
mma
aai
iil
lls
ss

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):




KLIM Mailing Standards Page 36 of 48


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):




KLIM Mailing Standards Page 37 of 48


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):




KLIM Mailing Standards Page 38 of 48


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

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):



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):




KLIM Mailing Standards Page 39 of 48


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.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




KLIM Mailing Standards Page 40 of 48









KLIM Mailing Standards Page 41 of 48

6.4.2 Second recall









KLIM Mailing Standards Page 42 of 48


6.4.3 Third recall






KLIM Mailing Standards Page 43 of 48





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




KLIM Mailing Standards Page 44 of 48









KLIM Mailing Standards Page 45 of 48

6.5.2 Second recall









KLIM Mailing Standards Page 46 of 48


6.5.3 Third recall






KLIM Mailing Standards Page 47 of 48





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.



KLIM Mailing Standards Page 48 of 48


7
77 H
HHo
oow
ww t
tto
oo d
ddi
iis
sst
tti
iin
nng
ggu
uui
iis
ssh
hh t
tth
hhe
ee r
rre
eec
cca
aal
lll
ll m
mma
aai
iil
lls
ss (
((
6
66)
)) f
ffr
rro
oom
mm t
tth
hhe
ee s
sst
tta
aan
nnd
dda
aar
rrd
dd r
rre
eeq
qqu
uue
ees
sst
tt
m
mma
aai
iil
ll (
((
3
33)
))?
??

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