references

Reference is a relation between objects in which one object designates, or acts as a means by which to connect to or link to, another object. read more at WikiPedia

  • Useful if you want to send dynamic content to the browser: a generated PDF for example...




    Network Working Group                                          R. Troost
    Request for Comments: 2183                           New Century Systems
    Updates: 1806                                                  S. Dorner
    Category: Standards Track                          QUALCOMM Incorporated
                                                            K. Moore, Editor
                                                     University of Tennessee
                                                                 August 1997


                   Communicating Presentation Information in
                               Internet Messages:
                      The Content-Disposition Header Field

    Status of this Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Abstract

       This memo provides a mechanism whereby messages conforming to the
       MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
       2049] can convey presentational information.  It specifies the
       "Content-Disposition" header field, which is optional and valid for
       any MIME entity ("message" or "body part").  Two values for this
       header field are described in this memo; one for the ordinary linear
       presentation of the body part, and another to facilitate the use of
       mail to transfer files.  It is expected that more values will be
       defined in the future, and procedures are defined for extending this
        set of values.

       This document is intended as an extension to MIME.  As such, the
       reader is assumed to be familiar with the MIME specifications, and
       [RFC 822].  The information presented herein supplements but does not
       replace that found in those documents.

       This document is a revision to the Experimental protocol defined in
       RFC 1806.  As compared to RFC 1806, this document contains minor
       editorial updates, adds new parameters needed to support the File
       Transfer Body Part, and references a separate specification for the
       handling of non-ASCII and/or very long parameter values.







    Troost, et. al.             Standards Track                     [Page 1]

    RFC 2183                  Content-Disposition                August 1997


    1.  Introduction

       MIME specifies a standard format for encapsulating multiple pieces of
       data into a single Internet message. That document does not address
       the issue of presentation styles; it provides a framework for the
       interchange of message content, but leaves presentation issues solely
       in the hands of mail user agent (MUA) implementors.

       Two common ways of presenting multipart electronic messages are as a
       main document with a list of separate attachments, and as a single
       document with the various parts expanded (displayed) inline. The
       display of an attachment is generally construed to require positive
       action on the part of the recipient, while inline message components
       are displayed automatically when the message is viewed. A mechanism
       is needed to allow the sender to transmit this sort of presentational
       information to the recipient; the Content-Disposition header provides
       this mechanism, allowing each component of a message to be tagged
       with an indication of its desired presentation semantics.

       Tagging messages in this manner will often be sufficient for basic
       message formatting. However, in many cases a more powerful and
       flexible approach will be necessary. The definition of such
       approaches is beyond the scope of this memo; however, such approaches
       can benefit from additional Content-Disposition values and
       parameters, to be defined at a later date.

       In addition to allowing the sender to specify the presentational
       disposition of a message component, it is desirable to allow her to
       indicate a default archival disposition; a filename. The optional
       "filename" parameter provides for this.  Further, the creation-date,
       modification-date, and read-date parameters allow preservation of
       those file attributes when the file is transmitted over MIME email.

       NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
       SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
       document, are to be interpreted as described in [RFC 2119].

    2.  The Content-Disposition Header Field

       Content-Disposition is an optional header field. In its absence, the
       MUA may use whatever presentation method it deems suitable.

       It is desirable to keep the set of possible disposition types small
       and well defined, to avoid needless complexity. Even so, evolving
       usage will likely require the definition of additional disposition
       types or parameters, so the set of disposition values is extensible;
       see below.




    Troost, et. al.             Standards Track                     [Page 2]

    RFC 2183                  Content-Disposition                August 1997


       In the extended BNF notation of [RFC 822], the Content-Disposition
       header field is defined as follows:

         disposition := "Content-Disposition" ":"
                        disposition-type
                        *(";" disposition-parm)

         disposition-type := "inline"
                           / "attachment"
                           / extension-token
                           ; values are not case-sensitive

         disposition-parm := filename-parm
                           / creation-date-parm
                           / modification-date-parm
                           / read-date-parm
                           / size-parm
                           / parameter

         filename-parm := "filename" "=" value

         creation-date-parm := "creation-date" "=" quoted-date-time

         modification-date-parm := "modification-date" "=" quoted-date-time

         read-date-parm := "read-date" "=" quoted-date-time

         size-parm := "size" "=" 1*DIGIT

         quoted-date-time := quoted-string
                          ; contents MUST be an RFC 822 `date-time'
                          ; numeric timezones (+HHMM or -HHMM) MUST be used



       NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
       parameter value containing only non-`tspecials' characters SHOULD be
       represented as a single `token'.  A short parameter value containing
       only ASCII characters, but including `tspecials' characters, SHOULD
       be represented as `quoted-string'.  Parameter values longer than 78
       characters, or which contain non-ASCII characters, MUST be encoded as
       specified in [RFC 2184].

       `Extension-token', `parameter', `tspecials' and `value' are defined
       according to [RFC 2045] (which references [RFC 822] in the definition
       of some of these tokens).  `quoted-string' and `DIGIT' are defined in
       [RFC 822].




    Troost, et. al.             Standards Track                     [Page 3]

    RFC 2183                  Content-Disposition                August 1997


    2.1  The Inline Disposition Type

       A bodypart should be marked `inline' if it is intended to be
       displayed automatically upon display of the message.  Inline
       bodyparts should be presented in the order in which they occur,
       subject to the normal semantics of multipart messages.

    2.2  The Attachment Disposition Type

       Bodyparts can be designated `attachment' to indicate that they are
       separate from the main body of the mail message, and that their
       display should not be automatic, but contingent upon some further
       action of the user.  The MUA might instead present the user of a
       bitmap terminal with an iconic representation of the attachments, or,
       on character terminals, with a list of attachments from which the
       user could select for viewing or storage.

    2.3  The Filename Parameter

       The sender may want to suggest a filename to be used if the entity is
       detached and stored in a separate file. If the receiving MUA writes
       the entity to a file, the suggested filename should be used as a
       basis for the actual filename, where possible.

       It is important that the receiving MUA not blindly use the suggested
       filename.  The suggested filename SHOULD be checked (and possibly
       changed) to see that it conforms to local filesystem conventions,
       does not overwrite an existing file, and does not present a security
       problem (see Security Considerations below).

       The receiving MUA SHOULD NOT respect any directory path information
       that may seem to be present in the filename parameter.  The filename
       should be treated as a terminal component only.  Portable
       specification of directory paths might possibly be done in the future
       via a separate Content-Disposition parameter, but no provision is
       made for it in this draft.

       Current [RFC 2045] grammar restricts parameter values (and hence
       Content-Disposition filenames) to US-ASCII.  We recognize the great
       desirability of allowing arbitrary character sets in filenames, but
       it is beyond the scope of this document to define the necessary
       mechanisms.  We expect that the basic [RFC 1521] `value'
       specification will someday be amended to allow use of non-US-ASCII
       characters, at which time the same mechanism should be used in the
       Content-Disposition filename parameter.






    Troost, et. al.             Standards Track                     [Page 4]

    RFC 2183                  Content-Disposition                August 1997


       Beyond the limitation to US-ASCII, the sending MUA may wish to bear
       in mind the limitations of common filesystems.  Many have severe
       length and character set restrictions.  Short alphanumeric filenames
       are least likely to require modification by the receiving system.

       The presence of the filename parameter does not force an
       implementation to write the entity to a separate file. It is
       perfectly acceptable for implementations to leave the entity as part
       of the normal mail stream unless the user requests otherwise. As a
       consequence, the parameter may be used on any MIME entity, even
       `inline' ones. These will not normally be written to files, but the
       parameter could be used to provide a filename if the receiving user
       should choose to write the part to a file.

    2.4 The Creation-Date parameter

       The creation-date parameter MAY be used to indicate the date at which
       the file was created.  If this parameter is included, the paramter
       value MUST be a quoted-string which contains a representation of the
       creation date of the file in [RFC 822] `date-time' format.

       UNIX and POSIX implementors are cautioned that the `st_ctime' file
       attribute of the `stat' structure is not the creation time of the
       file; it is thus not appropriate as a source for the creation-date
       parameter value.

    2.5 The Modification-Date parameter

       The modification-date parameter MAY be used to indicate the date at
       which the file was last modified.  If the modification-date parameter
       is included, the paramter value MUST be a quoted-string which
       contains a representation of the last modification date of the file
       in [RFC 822] `date-time' format.

    2.6 The Read-Date parameter

       The read-date parameter MAY be used to indicate the date at which the
       file was last read.  If the read-date parameter is included, the
       parameter value MUST be a quoted-string which contains a
       representation of the last-read date of the file in [RFC 822] `date-
       time' format.

    2.7 The Size parameter

       The size parameter indicates an approximate size of the file in
       octets.  It can be used, for example, to pre-allocate space before
       attempting to store the file, or to determine whether enough space
       exists.



    Troost, et. al.             Standards Track                     [Page 5]

    RFC 2183                  Content-Disposition                August 1997


    2.8  Future Extensions and Unrecognized Disposition Types

       In the likely event that new parameters or disposition types are
       needed, they should be registered with the Internet Assigned Numbers
       Authority (IANA), in the manner specified in Section 9 of this memo.

       Once new disposition types and parameters are defined, there is of
       course the likelihood that implementations will see disposition types
       and parameters they do not understand.  Furthermore, since x-tokens
       are allowed, implementations may also see entirely unregistered
       disposition types and parameters.

       Unrecognized parameters should be ignored. Unrecognized disposition
       types should be treated as `attachment'. The choice of `attachment'
       for unrecognized types is made because a sender who goes to the
       trouble of producing a Content-Disposition header with a new
       disposition type is more likely aiming for something more elaborate
       than inline presentation.

       Unless noted otherwise in the definition of a parameter, Content-
       Disposition parameters are valid for all dispositions.  (In contrast
       to MIME content-type parameters, which are defined on a per-content-
       type basis.) Thus, for example, the `filename' parameter still means
       the name of the file to which the part should be written, even if the
       disposition itself is unrecognized.

    2.9  Content-Disposition and Multipart

       If a Content-Disposition header is used on a multipart body part, it
       applies to the multipart as a whole, not the individual subparts.
       The disposition types of the subparts do not need to be consulted
       until the multipart itself is presented.  When the multipart is
       displayed, then the dispositions of the subparts should be respected.

       If the `inline' disposition is used, the multipart should be
       displayed as normal; however, an `attachment' subpart should require
       action from the user to display.

       If the `attachment' disposition is used, presentation of the
       multipart should not proceed without explicit user action.  Once the
       user has chosen to display the multipart, the individual subpart
       dispositions should be consulted to determine how to present the
       subparts.








    Troost, et. al.             Standards Track                     [Page 6]

    RFC 2183                  Content-Disposition                August 1997


    2.10  Content-Disposition and the Main Message

       It is permissible to use Content-Disposition on the main body of an
       [RFC 822] message.

    3.  Examples

       Here is a an example of a body part containing a JPEG image that is
       intended to be viewed by the user immediately:

            Content-Type: image/jpeg
            Content-Disposition: inline
            Content-Description: just a small picture of me

            

       The following body part contains a JPEG image that should be
       displayed to the user only if the user requests it. If the JPEG is
       written to a file, the file should be named "genome.jpg".  The
       recipient's user might also choose to set the last-modified date of
       the stored file to date in the modification-date parameter:

            Content-Type: image/jpeg
            Content-Disposition: attachment; filename=genome.jpeg;
              modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
            Content-Description: a complete map of the human genome

           

       The following is an example of the use of the `attachment'
       disposition with a multipart body part.  The user should see text-
       part-1 immediately, then take some action to view multipart-2.  After
       taking action to view multipart-2, the user will see text-part-2
       right away, and be required to take action to view jpeg-1.  Subparts
       are indented for clarity; they would not be so indented in a real
       message.















    Troost, et. al.             Standards Track                     [Page 7]

    RFC 2183                  Content-Disposition                August 1997


            Content-Type: multipart/mixed; boundary=outer
            Content-Description: multipart-1

            --outer
              Content-Type: text/plain
              Content-Disposition: inline
              Content-Description: text-part-1

              Some text goes here

            --outer
              Content-Type: multipart/mixed; boundary=inner
              Content-Disposition: attachment
              Content-Description: multipart-2

              --inner
                Content-Type: text/plain
                Content-Disposition: inline
                Content-Description: text-part-2

                Some more text here.

              --inner
                Content-Type: image/jpeg
                Content-Disposition: attachment
                Content-Description: jpeg-1

               
              --inner--
            --outer--

    4.  Summary

       Content-Disposition takes one of two values, `inline' and
       `attachment'.  `Inline' indicates that the entity should be
       immediately displayed to the user, whereas `attachment' means that
       the user should take additional action to view the entity.

       The `filename' parameter can be used to suggest a filename for
       storing the bodypart, if the user wishes to store it in an external
       file.










    Troost, et. al.             Standards Track                     [Page 8]

    RFC 2183                  Content-Disposition                August 1997


    5.  Security Considerations

       There are security issues involved any time users exchange data.
       While these are not to be minimized, neither does this memo change
       the status quo in that regard, except in one instance.

       Since this memo provides a way for the sender to suggest a filename,
       a receiving MUA must take care that the sender's suggested filename
       does not represent a hazard. Using UNIX as an example, some hazards
       would be:

       +    Creating startup files (e.g., ".login").

       +    Creating or overwriting system files (e.g., "/etc/passwd").

       +    Overwriting any existing file.

       +    Placing executable files into any command search path
            (e.g., "~/bin/more").

       +    Sending the file to a pipe (e.g., "| sh").

       In general, the receiving MUA should not name or place the file such
       that it will get interpreted or executed without the user explicitly
       initiating the action.

       It is very important to note that this is not an exhaustive list; it
       is intended as a small set of examples only.  Implementors must be
       alert to the potential hazards on their target systems.

    6.  References

       [RFC 2119]
            Bradner, S., "Key words for use in RFCs to Indicate Requirement
            Levels", RFC 2119, March 1997.

       [RFC 2184]
            Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
            Character Sets, Lanaguage, and Continuations", RFC 2184, August
            1997.

       [RFC 2045]
            Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
            Extensions) Part One: Format of Internet Message Bodies", RFC
            2045, December 1996.






    Troost, et. al.             Standards Track                     [Page 9]

    RFC 2183                  Content-Disposition                August 1997


       [RFC 2046]
            Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
            Extensions) Part Two: Media Types", RFC 2046, December 1996.

       [RFC 2047]
            Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
            Three: Message Header Extensions for non-ASCII Text", RFC 2047,
            December 1996.

       [RFC 2048]
            Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
            Internet Mail Extensions) Part Four: Registration Procedures",
            RFC 2048, December 1996.

       [RFC 2049]
            Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
            Extensions) Part Five: Conformance Criteria and Examples", RFC
            2049, December 1996.

       [RFC 822]
            Crocker, D., "Standard for the Format of ARPA Internet Text
            Messages", STD 11, RFC 822, UDEL, August 1982.

    7.  Acknowledgements

       We gratefully acknowledge the help these people provided during the
       preparation of this draft:

            Nathaniel Borenstein
            Ned Freed
            Keith Moore
            Dave Crocker
            Dan Pritchett


















    Troost, et. al.             Standards Track                    [Page 10]

    RFC 2183                  Content-Disposition                August 1997


    8.  Authors' Addresses

       You should blame the editor of this version of the document for any
       changes since RFC 1806:

            Keith Moore
            Department of Computer Science
            University of Tennessee, Knoxville
            107 Ayres Hall
            Knoxville TN  37996-1301
            USA

            Phone: +1 (423) 974-5067
            Fax: +1 (423) 974-8296
            Email: This email address is being protected from spambots. You need JavaScript enabled to view it.


            The authors of RFC 1806 are:

            Rens Troost
            New Century Systems
            324 East 41st Street 804
            New York, NY, 10017 USA

            Phone: +1 (212) 557-2050
            Fax: +1 (212) 557-2049
            EMail: This email address is being protected from spambots. You need JavaScript enabled to view it.


            Steve Dorner
            QUALCOMM Incorporated
            6455 Lusk Boulevard
            San Diego, CA 92121
            USA

            EMail: This email address is being protected from spambots. You need JavaScript enabled to view it.


    9. Registration of New Content-Disposition Values and Parameters

       New Content-Disposition values (besides "inline" and "attachment")
       may be defined only by Internet standards-track documents, or in
       Experimental documents approved by the Internet Engineering Steering
       Group.







    Troost, et. al.             Standards Track                    [Page 11]

    RFC 2183                  Content-Disposition                August 1997


       New content-disposition parameters may be registered by supplying the
       information in the following template and sending it via electronic
       mail to This email address is being protected from spambots. You need JavaScript enabled to view it.:

         To: This email address is being protected from spambots. You need JavaScript enabled to view it.
         Subject: Registration of new Content-Disposition parameter

         Content-Disposition parameter name:

         Allowable values for this parameter:
              (If the parameter can only assume a small number of values,
              list each of those values.  Otherwise, describe the values
              that the parameter can assume.)
         Description:
              (What is the purpose of this parameter and how is it used?)

    10. Changes since RFC 1806

       The following changes have been made since the earlier version of
       this document, published in RFC 1806 as an Experimental protocol:

       +    Updated references to MIME documents.  In some cases this
            involved substituting a reference to one of the current MIME
            RFCs for a reference to RFC 1521; in other cases, a reference to
            RFC 1521 was simply replaced with the word "MIME".

       +    Added  a section on registration procedures, since none of the
            procedures in RFC 2048 seemed to be appropriate.

       +    Added new parameter types: creation-date, modification-date,
            read-date, and size.


       +    Incorporated a reference to draft-freed-pvcsc-* for encoding
            long or non-ASCII parameter values.

       +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
            keywords.

    Troost, et. al.             Standards Track                    [Page 12]

  • ISO 8859-1 Symbol Entities

    Result Description Entity Name Entity Number
      non-breaking space &nbsp; &160;
    ¡ inverted exclamation mark &iexcl; &161;
    ¤ currency &curren; &164;
    ¢ cent &cent; &162;
    £ pound &pound; &163;
    ¥ yen &yen; &165;
    ¦ broken vertical bar &brvbar; &166;
    § section &sect; &167;
    ¨ spacing diaeresis &uml; &168;
    © copyright &copy; &169;
    ª feminine ordinal indicator &ordf; &170;
    « angle quotation mark (left) &laquo; &171;
    ¬ negation &not; &172;
    ­ soft hyphen &shy; &173;
    ® registered trademark &reg; &174;
    ™ trademark &trade; &8482;
    ¯ spacing macron &macr; &175;
    ° degree &deg; &176;
    ± plus-or-minus  &plusmn; &177;
    ² superscript 2 &sup2; &178;
    ³ superscript 3 &sup3; &179;
    ´ spacing acute &acute; &180;
    µ micro &micro; &181;
    paragraph &para; &182;
    · middle dot &middot; &183;
    ¸ spacing cedilla &cedil; &184;
    ¹ superscript 1 &sup1; &185;
    º masculine ordinal indicator &ordm; &186;
    » angle quotation mark (right) &raquo; &187;
    ¼ fraction 1/4 &frac14; &188;
    ½ fraction 1/2 &frac12; &189;
    ¾ fraction 3/4 &frac34; &190;
    ¿ inverted question mark &iquest; &191;
    × multiplication &times; &215;
    ÷ division &divide; &247;
    À capital a, grave accent &Agrave; &192;
    Á capital a, acute accent &Aacute; &193;
    Â capital a, circumflex accent &Acirc; &194;
    Ã capital a, tilde &Atilde; &195;
    Ä capital a, umlaut mark &Auml; &196;
    Å capital a, ring &Aring; &197;
    Æ capital ae &AElig; &198;
    Ç capital c, cedilla &Ccedil; &199;
    È capital e, grave accent &Egrave; &200;
    É capital e, acute accent &Eacute; &201;
    Ê capital e, circumflex accent &Ecirc; &202;
    Ë capital e, umlaut mark &Euml; &203;
    Ì capital i, grave accent &Igrave; &204;
    Í capital i, acute accent &Iacute; &205;
    Î capital i, circumflex accent &Icirc; &206;
    Ï capital i, umlaut mark &Iuml; &207;
    Ð capital eth, Icelandic &ETH; &208;
    Ñ capital n, tilde &Ntilde; &209;
    Ò capital o, grave accent &Ograve; &210;
    Ó capital o, acute accent &Oacute; &211;
    Ô capital o, circumflex accent &Ocirc; &212;
    Õ capital o, tilde &Otilde; &213;
    Ö capital o, umlaut mark &Ouml; &214;
    Ø capital o, slash &Oslash; &216;
    Ù capital u, grave accent &Ugrave; &217;
    Ú capital u, acute accent &Uacute; &218;
    Û capital u, circumflex accent &Ucirc; &219;
    Ü capital u, umlaut mark &Uuml; &220;
    Ý capital y, acute accent &Yacute; &221;
    Þ capital THORN, Icelandic &THORN; &222;
    ß small sharp s, German &szlig; &223;
    à small a, grave accent &agrave; &224;
    á small a, acute accent &aacute; &225;
    â small a, circumflex accent &acirc; &226;
    ã small a, tilde &atilde; &227;
    ä small a, umlaut mark &auml; &228;
    å small a, ring &aring; &229;
    æ small ae &aelig; &230;
    ç small c, cedilla &ccedil; &231;
    è small e, grave accent &egrave; &232;
    é small e, acute accent &eacute; &233;
    ê small e, circumflex accent &ecirc; &234;
    ë small e, umlaut mark &euml; &235;
    ì small i, grave accent &igrave; &236;
    í small i, acute accent &iacute; &237;
    î small i, circumflex accent &icirc; &238;
    ï small i, umlaut mark &iuml; &239;
    ð small eth, Icelandic &eth; &240;
    ñ small n, tilde &ntilde; &241;
    ò small o, grave accent &ograve; &242;
    ó small o, acute accent &oacute; &243;
    ô small o, circumflex accent &ocirc; &244;
    õ small o, tilde &otilde; &245;
    ö small o, umlaut mark &ouml; &246;
    ø small o, slash &oslash; &248;
    ù small u, grave accent &ugrave; &249;
    ú small u, acute accent &uacute; &250;
    û small u, circumflex accent &ucirc; &251;
    ü small u, umlaut mark &uuml; &252;
    ý small y, acute accent &yacute; &253;
    þ small thorn, Icelandic &thorn; &254;
    ÿ small y, umlaut mark &yuml; &255;
    Πcapital ligature OE &OElig; &338;
    œ small ligature oe &oelig; &339;
    Š capital S with caron &Scaron; &352;
    š small S with caron &scaron; &353;
    Ÿ capital Y with diaeres &Yuml; &376;
    ˆ modifier letter circumflex accent &circ; &710;
    ˜ small tilde &tilde; &732;
      en space &ensp; &8194;
      em space &emsp; &8195;
      thin space &thinsp; &8201;
    &8204; zero width non-joiner &zwnj; &8204;
    &8205; zero width joiner &zwj; &8205;
    &8206; left-to-right mark &lrm; &8206;
    &8207; right-to-left mark &rlm; &8207;
    – en dash &ndash; &8211;
    — em dash &mdash; &8212;
    ‘ left single quotation mark &lsquo; &8216;
    ’ right single quotation mark &rsquo; &8217;
    ‚ single low-9 quotation mark &sbquo; &8218;
    “ left double quotation mark &ldquo; &8220;
    ” right double quotation mark &rdquo; &8221;
    „ double low-9 quotation mark &bdquo; &8222;
    † dagger &dagger; &8224;
    ‡ double dagger &Dagger; &8225;
    … horizontal ellipsis &hellip; &8230;
    ‰ per mille  &permil; &8240;
    ‹ single left-pointing angle quotation &lsaquo; &8249;
    › single right-pointing angle quotation &rsaquo; &8250;
    € euro &euro; &8364;
  • Message Description
    100 Continue Only a part of the request has been received by the server, but as long as it
     has not been rejected, the client should continue with the request
    101 Switching Protocols The server switches protocol
    200 OK The request is OK
    201 Created The request is complete, and a new resource is created 
    202 Accepted The request is accepted for processing, but the processing is not complete
    203 Non-authoritative Information  
    204 No Content  
    205 Reset Content  
    206 Partial Content  
    300 Multiple Choices A link list. The user can select a link and go to that location. Maximum five addresses  
    301 Moved Permanently The requested page has moved to a new url 
    302 Found The requested page has moved temporarily to a new url 
    303 See Other The requested page can be found under a different url 
    304 Not Modified  
    305 Use Proxy  
    306 Unused This code was used in a previous version. It is no longer used, but the code is reserved
    307 Temporary Redirect The requested page has moved temporarily to a new url
    400 Bad Request The server did not understand the request
    401 Unauthorized The requested page needs a username and a password
    402 Payment Required You can not use this code yet
    403 Forbidden Access is forbidden to the requested page
    404 Not Found The server can not find the requested page
    405 Method Not Allowed The method specified in the request is not allowed
    406 Not Acceptable The server can only generate a response that is not accepted by the client
    407 Proxy Authentication Required You must authenticate with a proxy server before this request can be served
    408 Request Timeout The request took longer than the server was prepared to wait
    409 Conflict The request could not be completed because of a conflict
    410 Gone The requested page is no longer available 
    411 Length Required The "Content-Length" is not defined. The server will not accept the request without it 
    412 Precondition Failed The precondition given in the request evaluated to false by the server
    413 Request Entity Too Large The server will not accept the request, because the request entity is too large
    414 Request-url Too Long The server will not accept the request, because the url is too long.
    Occurs when you convert a "post" request to a "get" request with a
    long query information 
    415 Unsupported Media Type The server will not accept the request, because the media type is not supported 
    416   
    417 Expectation Failed  
    500 Internal Server Error The request was not completed. The server met an unexpected condition
    501 Not Implemented The request was not completed. The server did not support the functionality required
    502 Bad Gateway The request was not completed. The server received an invalid response from the
    upstream server
    503 Service Unavailable The request was not completed. The server is temporarily overloading or down
    504 Gateway Timeout The gateway has timed out
    505 HTTP Version Not Supported The server does not support the "http protocol" version
  •  
     Character  XML ISO code  HTML entity   Character  XML ISO code  HTML entity 
    À&192;&Agrave; Ã&224;&agrave;
    Ã?&193;&Aacute; Ã¡&225;&aacute;
    Â&194;&Acirc; Ã¢&226;&acirc;
    Ã&195;&Atilde; Ã£&227;&atilde;
    Ä&196;&Auml; ä&228;&auml;
    Å&197;&Aring; Ã¥&229;&aring;
    Æ&198;&Aelig; Ã¦&230;&aelig;
    Ç&199;&Ccedil; Ã§&231;&ccedil;
    È&200;&Egrave; Ã¨&232;&egrave;
    É&201;&Eacute; Ã©&233;&eacute;
    Ê&202;&Ecirc; Ãª&234;&ecirc;
    Ë&203;&Euml; Ã«&235;&euml;
    Ì&204;&Igrave; Ã¬&236;&igrave;
    Ã?&205;&Iacute; Ã­&237;&iacute;
    Î&206;&Icirc; Ã®&238;&icirc;
    Ã?&207;&Iuml; Ã¯&239;&iuml;
    Ã?&208;&ETH; Ã°&240;&eth;
    Ñ&209;&Ntilde; Ã±&241;&ntilde;
    Ò&210;&Ograve; Ã²&242;&ograve;
    Ó&211;&Oacute; Ã³&243;&oacute;
    Ô&212;&Ocirc; Ã´&244;&ocirc;
    Õ&213;&Otilde; Ãµ&245;&otilde;
    Ö&214;&Ouml; ö&246;&ouml;
    ×&215;&times; Ã·&247;&divide;
    Ø&216;&Oslash; Ã¸&248;&oslash;
    Ù&217;&Ugrave; Ã¹&249;&ugrave;
    Ú&218;&Uacute; Ãº&250;&uacute;
    Û&219;&Ucirc; Ã»&251;&ucirc;
    Ü&220;&Uuml; ü&252;&uuml;
    Ã?&221;&Yacute; Ã½&253;&yacute;
    Þ&222;&THORN; Ã¾&254;&thorn;
    ß&223;&szlig; Ã¿&255;&yuml;
     &129;  Â¡&161;&iexcl;
    ‚&130;  Â¢&162;&cent;
    ƒ&131;  Â£&163;&pound;
    „&132;  Â¤&164;&curren;
    …&133;  Â¥&165;&yen;
    â€&134;  Â¦&166;&brvbar;
    ‡&135;  Â§&167;&sect;
    ˆ&136;  Â¨&168;&uml;
    ‰&137;  Â©&169;&copy;
    Å&138;  Âª&170;&ordf;
    ‹&139;  Â«&171;&laquo;
    Œ&140;  Â¬&172;&not;
     &141;  Â­&173;&shy;
    Ž&142;  Â®&174;&reg;
     &143;  Â¯&175;&masr;
     &144;  Â°&176;&deg;
    ‘&145;  Â±&177;&plusmn;
    ’&146;  Â²&178;&sup2;
    “&147;  Â³&179;&sup3;
    â€?&148;  Â´&180;&acute;
    •&149;  Âµ&181;&micro;
    –&150;  Â¶&182;&para;
    —&151;  Â·&183;&middot;
    ˜&152;  Â¸&184;&cedil;
    ™&153;  Â¹&185;&supl;
    Å¡&154;  Âº&186;&ordm;
    ›&155;  Â»&187;&raquo;
    œ&156;  Â¼&188;&frac14;
     &157;  Â½&189;&frac12;
    ž&158;  Â¾&190;&frac34;
    Ÿ&159;  Â¿&191;&iquest;
    Space&160;&nbsp;    
  • TimeZone represents a time zone offset, and also figures out daylight savings. Typically, you get a TimeZone using getDefault which creates a TimeZone based on the time zone where the program is running. For example, for a program running in Japan, getDefault creates a TimeZone object based on Japanese Standard Time.

    You can also get a TimeZone using getTimeZone along with a time zone ID. For instance, the time zone ID for the U.S. Pacific Time zone is "America/Los_Angeles". So, you can get a U.S. Pacific Time TimeZone object with

    TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");

    You can force the Java Virtual Machine to use a specific TimeZone by adding a –D to its start parameter

    -Duser.timezone="America/Los_Angeles"

    In this example any server located outside the U.S. Pacific Time zone can still create timestamp like it would be in the U.S. Pacific Time zone.

    All the available TimeZone from java.util.TimeZone  are listed below for your convenience:

    ACT
    AET
    Africa/Abidjan
    Africa/Accra
    Africa/Addis_Ababa
    Africa/Algiers
    Africa/Asmera
    Africa/Bamako
    Africa/Bangui
    Africa/Banjul
    Africa/Bissau
    Africa/Blantyre
    Africa/Brazzaville
    Africa/Bujumbura
    Africa/Cairo
    Africa/Casablanca
    Africa/Ceuta
    Africa/Conakry
    Africa/Dakar
    Africa/Dar_es_Salaam
    Africa/Djibouti
    Africa/Douala
    Africa/El_Aaiun
    Africa/Freetown
    Africa/Gaborone
    Africa/Harare
    Africa/Johannesburg
    Africa/Kampala
    Africa/Khartoum
    Africa/Kigali
    Africa/Kinshasa
    Africa/Lagos
    Africa/Libreville
    Africa/Lome
    Africa/Luanda
    Africa/Lubumbashi
    Africa/Lusaka
    Africa/Malabo
    Africa/Maputo
    Africa/Maseru
    Africa/Mbabane
    Africa/Mogadishu
    Africa/Monrovia
    Africa/Nairobi
    Africa/Ndjamena
    Africa/Niamey
    Africa/Nouakchott
    Africa/Ouagadougou
    Africa/Porto-Novo
    Africa/Sao_Tome
    Africa/Timbuktu
    Africa/Tripoli
    Africa/Tunis
    Africa/Windhoek
    AGT
    America/Adak
    America/Anchorage
    America/Anguilla
    America/Antigua
    America/Araguaina
    America/Aruba
    America/Asuncion
    America/Atka
    America/Barbados
    America/Belem
    America/Belize
    America/Boa_Vista
    America/Bogota
    America/Boise
    America/Buenos_Aires
    America/Cambridge_Bay
    America/Cancun
    America/Caracas
    America/Catamarca
    America/Cayenne
    America/Cayman
    America/Chicago
    America/Chihuahua
    America/Cordoba
    America/Costa_Rica
    America/Cuiaba
    America/Curacao
    America/Danmarkshavn
    America/Dawson
    America/Dawson_Creek
    America/Denver
    America/Detroit
    America/Dominica
    America/Edmonton
    America/Eirunepe
    America/El_Salvador
    America/Ensenada
    America/Fort_Wayne
    America/Fortaleza
    America/Glace_Bay
    America/Godthab
    America/Goose_Bay
    America/Grand_Turk
    America/Grenada
    America/Guadeloupe

    America/Guatemala
    America/Guayaquil
    America/Guyana
    America/Halifax
    America/Havana
    America/Hermosillo
    America/Indiana/Indianapolis
    America/Indiana/Knox
    America/Indiana/Marengo
    America/Indiana/Vevay
    America/Indianapolis
    America/Inuvik
    America/Iqaluit
    America/Jamaica
    America/Jujuy
    America/Juneau
    America/Kentucky/Louisville
    America/Kentucky/Monticello
    America/Knox_IN
    America/La_Paz
    America/Lima
    America/Los_Angeles
    America/Louisville
    America/Maceio
    America/Managua
    America/Manaus
    America/Martinique
    America/Mazatlan
    America/Mendoza
    America/Menominee
    America/Merida
    America/Mexico_City
    America/Miquelon
    America/Monterrey
    America/Montevideo
    America/Montreal
    America/Montserrat
    America/Nassau
    America/New_York
    America/Nipigon
    America/Nome
    America/Noronha
    America/North_Dakota/Center
    America/Panama
    America/Pangnirtung
    America/Paramaribo
    America/Phoenix
    America/Port-au-Prince
    America/Port_of_Spain
    America/Porto_Acre
    America/Porto_Velho
    America/Puerto_Rico
    America/Rainy_River
    America/Rankin_Inlet
    America/Recife
    America/Regina
    America/Rio_Branco
    America/Rosario
    America/Santiago
    America/Santo_Domingo
    America/Sao_Paulo
    America/Scoresbysund
    America/Shiprock
    America/St_Johns
    America/St_Kitts
    America/St_Lucia
    America/St_Thomas
    America/St_Vincent
    America/Swift_Current
    America/Tegucigalpa
    America/Thule
    America/Thunder_Bay
    America/Tijuana
    America/Tortola
    America/Vancouver
    America/Virgin
    America/Whitehorse
    America/Winnipeg
    America/Yakutat
    America/Yellowknife
    Antarctica/Casey
    Antarctica/Davis
    Antarctica/DumontDUrville
    Antarctica/Mawson
    Antarctica/McMurdo
    Antarctica/Palmer
    Antarctica/Rothera
    Antarctica/South_Pole
    Antarctica/Syowa
    Antarctica/Vostok
    Arctic/Longyearbyen
    ART
    Asia/Aden
    Asia/Almaty
    Asia/Amman
    Asia/Anadyr
    Asia/Aqtau
    Asia/Aqtobe
    Asia/Ashgabat

    Asia/Ashkhabad
    Asia/Baghdad
    Asia/Bahrain
    Asia/Baku
    Asia/Bangkok
    Asia/Beirut
    Asia/Bishkek
    Asia/Brunei
    Asia/Calcutta
    Asia/Choibalsan
    Asia/Chongqing
    Asia/Chungking
    Asia/Colombo
    Asia/Dacca
    Asia/Damascus
    Asia/Dhaka
    Asia/Dili
    Asia/Dubai
    Asia/Dushanbe
    Asia/Gaza
    Asia/Harbin
    Asia/Hong_Kong
    Asia/Hovd
    Asia/Irkutsk
    Asia/Istanbul
    Asia/Jakarta
    Asia/Jayapura
    Asia/Jerusalem
    Asia/Kabul
    Asia/Kamchatka
    Asia/Karachi
    Asia/Kashgar
    Asia/Katmandu
    Asia/Krasnoyarsk
    Asia/Kuala_Lumpur
    Asia/Kuching
    Asia/Kuwait
    Asia/Macao
    Asia/Macau
    Asia/Magadan
    Asia/Makassar
    Asia/Manila
    Asia/Muscat
    Asia/Nicosia
    Asia/Novosibirsk
    Asia/Omsk
    Asia/Oral
    Asia/Phnom_Penh
    Asia/Pontianak
    Asia/Pyongyang
    Asia/Qatar
    Asia/Qyzylorda
    Asia/Rangoon
    Asia/Riyadh
    Asia/Riyadh87
    Asia/Riyadh88
    Asia/Riyadh89
    Asia/Saigon
    Asia/Sakhalin
    Asia/Samarkand
    Asia/Seoul
    Asia/Shanghai
    Asia/Singapore
    Asia/Taipei
    Asia/Tashkent
    Asia/Tbilisi
    Asia/Tehran
    Asia/Tel_Aviv
    Asia/Thimbu
    Asia/Thimphu
    Asia/Tokyo
    Asia/Ujung_Pandang
    Asia/Ulaanbaatar
    Asia/Ulan_Bator
    Asia/Urumqi
    Asia/Vientiane
    Asia/Vladivostok
    Asia/Yakutsk
    Asia/Yekaterinburg
    Asia/Yerevan
    AST
    Atlantic/Azores
    Atlantic/Bermuda
    Atlantic/Canary
    Atlantic/Cape_Verde
    Atlantic/Faeroe
    Atlantic/Jan_Mayen
    Atlantic/Madeira
    Atlantic/Reykjavik
    Atlantic/South_Georgia
    Atlantic/St_Helena
    Atlantic/Stanley
    Australia/ACT
    Australia/Adelaide
    Australia/Brisbane
    Australia/Broken_Hill
    Australia/Canberra
    Australia/Darwin
    Australia/Hobart
    Australia/LHI

    Australia/Lindeman
    Australia/Lord_Howe
    Australia/Melbourne
    Australia/North
    Australia/NSW
    Australia/Perth
    Australia/Queensland
    Australia/South
    Australia/Sydney
    Australia/Tasmania
    Australia/Victoria
    Australia/West
    Australia/Yancowinna
    BET
    Brazil/Acre
    Brazil/DeNoronha
    Brazil/East
    Brazil/West
    BST
    Canada/Atlantic
    Canada/Central
    Canada/East-Saskatchewan
    Canada/Eastern
    Canada/Mountain
    Canada/Newfoundland
    Canada/Pacific
    Canada/Saskatchewan
    Canada/Yukon
    CAT
    CET
    Chile/Continental
    Chile/EasterIsland
    CNT
    CST
    CST6CDT
    CTT
    Cuba
    EAT
    ECT
    EET
    Egypt
    Eire
    EST
    EST5EDT
    Etc/GMT
    Etc/GMT+0
    Etc/GMT+1
    Etc/GMT+10
    Etc/GMT+11
    Etc/GMT+12
    Etc/GMT+2
    Etc/GMT+3
    Etc/GMT+4
    Etc/GMT+5
    Etc/GMT+6
    Etc/GMT+7
    Etc/GMT+8
    Etc/GMT+9
    Etc/GMT-0
    Etc/GMT-1
    Etc/GMT-10
    Etc/GMT-11
    Etc/GMT-12
    Etc/GMT-13
    Etc/GMT-14
    Etc/GMT-2
    Etc/GMT-3
    Etc/GMT-4
    Etc/GMT-5
    Etc/GMT-6
    Etc/GMT-7
    Etc/GMT-8
    Etc/GMT-9
    Etc/GMT0
    Etc/Greenwich
    Etc/UCT
    Etc/Universal
    Etc/UTC
    Etc/Zulu
    Europe/Amsterdam
    Europe/Andorra
    Europe/Athens
    Europe/Belfast
    Europe/Belgrade
    Europe/Berlin
    Europe/Bratislava
    Europe/Brussels
    Europe/Bucharest
    Europe/Budapest
    Europe/Chisinau
    Europe/Copenhagen
    Europe/Dublin
    Europe/Gibraltar
    Europe/Helsinki
    Europe/Istanbul
    Europe/Kaliningrad
    Europe/Kiev
    Europe/Lisbon
    Europe/Ljubljana

    Europe/London
    Europe/Luxembourg
    Europe/Madrid
    Europe/Malta
    Europe/Minsk
    Europe/Monaco
    Europe/Moscow
    Europe/Nicosia
    Europe/Oslo
    Europe/Paris
    Europe/Prague
    Europe/Riga
    Europe/Rome
    Europe/Samara
    Europe/San_Marino
    Europe/Sarajevo
    Europe/Simferopol
    Europe/Skopje
    Europe/Sofia
    Europe/Stockholm
    Europe/Tallinn
    Europe/Tirane
    Europe/Tiraspol
    Europe/Uzhgorod
    Europe/Vaduz
    Europe/Vatican
    Europe/Vienna
    Europe/Vilnius
    Europe/Warsaw
    Europe/Zagreb
    Europe/Zaporozhye
    Europe/Zurich
    GB
    GB-Eire
    GMT
    GMT0
    Greenwich
    Hongkong
    HST
    Iceland
    IET
    Indian/Antananarivo
    Indian/Chagos
    Indian/Christmas
    Indian/Cocos
    Indian/Comoro
    Indian/Kerguelen
    Indian/Mahe
    Indian/Maldives
    Indian/Mauritius
    Indian/Mayotte
    Indian/Reunion
    Iran
    Israel
    IST
    Jamaica
    Japan
    JST
    Kwajalein
    Libya
    MET
    Mexico/BajaNorte
    Mexico/BajaSur
    Mexico/General
    Mideast/Riyadh87
    Mideast/Riyadh88
    Mideast/Riyadh89
    MIT
    MST
    MST7MDT
    Navajo
    NET
    NST
    NZ
    NZ-CHAT

    Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Johnston Pacific/Kiritimati Pacific/Kosrae Pacific/Kwajalein Pacific/Majuro Pacific/Marquesas Pacific/Midway Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Samoa Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis Pacific/Yap PLT PNT Poland Portugal PRC PRT PST PST8PDT ROK Singapore SST SystemV/AST4 SystemV/AST4ADT SystemV/CST6 SystemV/CST6CDT SystemV/EST5 SystemV/EST5EDT SystemV/HST10 SystemV/MST7 SystemV/MST7MDT SystemV/PST8 SystemV/PST8PDT SystemV/YST9 SystemV/YST9YDT Turkey UCT Universal US/Alaska US/Aleutian US/Arizona US/Central US/East-Indiana US/Eastern US/Hawaii US/Indiana-Starke US/Michigan US/Mountain US/Pacific US/Pacific-New US/Samoa UTC VST W-SU WET Zulu

    see also References

  • WHOAHHHHHHHHHHH

    An Ajax web enabled API lookup service for CSS, HTML, XSL, XSD, PHP, MySQL, Java, J2EE, Struts, DITA and other technologies.

    RDV immediately to http://www.gotapi.com/
  • Zwischenzeugnis (Interim Report 2004, original on demand)

    Herr Cédric Walter, geboren am 3. Oktober 1973, ist seit dem 1. März 2000 bei unserer Versicherungsgesellschaft angestellt. Vom 1. März 2000 bis 31. Juli 2000 absolvierte er im Rahmen seiner Ausbildung zum Informatiker bei uns ein Praktikum.

    Per 1. August 2000 wurde er als Analytiker Programmierer im Team LIFE der Informatik angestellt. In dieser Funktion war er zuständig für die Entwicklung und Einführung einer Offert-Applikation auf dem internet, welche den externen Vertriebskanälen die Möglichkeit bietet, Offerten direkt auf dem Internet abzuschliessen. Die Umsetzung erfolgte für die Oberfläche in HTML und für die Business-Komponente in Java und C++. Für die Dokumentation wurde Style-Report benutzt

    Per 1. Juli 2001 wechselte er intern in den Bereich eBusiness Center der Helvetia Patria Gruppe. In dieser Funktion gehören im wesentlichen folgende Tätigkeiten zu seinem Aufgabengebiet:

    • Benutzung, Weiterentwicklung und Spezialisierung von gruppenweiten eBusiness-Plattform -Komponenten,
    • Programmierung von eBusiness Versicherungsapplikationen mittels J2EE und XML, XSL, FOP
    • Integrations-und Deploymentverantwortung über eBusiness-Projekte und Standard-Komponente,
    • Aufbau und Umsetzung der gruppenweiten Informationsplattform für eBusiness Entwickler mittels phpnuke, Ausbildungs-und Dokumentationsunterlagen,
    • Know-how Transfer und Support laufender internationaler Projekte

    Herr Walter ist ein ruhiger, zuverlässiger und in besonderem Masse vertrauenswürdiger Mitarbeiter. Er ist ausgesprochen kreativ, hat immer wieder ausgezeichnete Ideen und gibt wertvolle Anregungen. Er ergreift selbstständig alle erforderlichen Massnahmen und führt sie entschlossen durch. Herr Walter verfügt über ein abgesichertes Fachwissen und eine schnelle Auffassungsgabe, welches ihm ermöglicht auch schwierigste Aufgaben zu lösen. Wir kennen ihn als unermüdlichen und sehr belastbaren Mitarbeiter, der auch unter schwierigen Arbeitsbedingungen alle Aufgaben bewältigt. Besonders hervorzuheben ist sein grosser persönlicher Einsatz auch über die normale Arbeitszeit hinaus. Durch sein rationelle und sorgfältige Arbeitsweise erbringt er ein ausgezeichnete Leistung.

    Sein Verhalten zu Vorgesetzten und Mitarbeitenden ist vorbildlich und er wird von allen geschätzt und ist beliebt.

    Dieses Zwischenzeugnis wird aufgrund einer Reorganisation im Bereich Informatik und der damit verbundenen internen Stellenwechsels von Herrn Walter erstellt. Wir bedauern seinen Weggang vom eCenter sehr und danken ihm für die wertvolle Mitarbeit. Für die Zukunft wünschen wir ihm alles Gute und viel Erfolg.

    Helvetia Patria Versicherungen.
    D. Beck
    Ressortleiter eBusiness Center
    Informatik
    D. Schuster
    Personalfachfrau
    Human Ressources + Dienste


    Basel, 30. juni 2004


  • Herr Cédric Walter, geboren am 3. Oktober 1973, ist seit dem 1. März 2000 in unserer Versicherungsgesellschaft angestellt. Für die Zeit vom März 2000 bis Juni 2004 verweisen wir auf unser Zwischenzeugnis von 30. Juni 2004.

    Herr Walter erledigt als Anwendungsentwickler im Ressort Anwendungen Basel im Wesentlichen folgende Aufgaben:

    • Benutzung, Weiterentwicklung und Spezialisierung von gruppenweiten eBusiness-Plattformkomponenten
    • Programmierung von eBusiness Versicherungsapplikationen mittels J2EE, XML, JSF (Programm zur Offerterstellung im Einzelleben-Versicherungsbereich)
    • Wartung und Weiterentwicklung der neuen Infrastruktur für die Entwicklung des Einzelleben-Offertsystem
    • Mitarbeit bei der Untersuchung einer neuen Entwicklungsplattform für die  Entwicklung des neuen Präsentation-Layer des Einzel-leben-Verwaltungssystems
    • Know how Transfer und Support laufender Projekte.

    Wir kennen Herr Walter als pflichtbewussten und im besonderen Masse vertrauenswürdigen und verantwortungsvollen Mitarbeiter. Er verfügt über ein hervorragendes Fachwissen und im technischen Bereich über überdurchschnittliche Fähigkeiten, welche ihm ermöglichen, auch sehr schwierige Aufgaben zu lösen. Er hat immer ausgezeichnete Ideen, gibt wertvolle Anregungen, ergreift selbständig alle notwendigen Massnahmen und führt diese erfolgreich durch. Herr Walter ist belastbar und erbringt auch unter schwierigen Arbeitsbedingungen eine sehr gute Leistung.

    Durch sein kooperatives und freundliches Verhalten ist Herr Walter bei Vorgesetzten, Mitarbeitenden und Kunden geschätzt und beliebt.

    Dieses Zwischenzeugnis erstellen wir aufgrund eines per 1. Januar 2007 stattgefundenen Vorgesetztenwechsels. Wir danken Herrn Walter für die bisher geleisteten wertvollen Dienste und wünschen ihm weiterhin viel Erfolg und Zufriedenheit.

    Helvetia Versicherungen.
    Human Ressources + Dienste
    Dominique Bruat
    Teamleiter Anwendungen basel
    Monika Haering
    Personalleiterin


    Basel, 31. Januar 2007