Subject: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11

From: [email-masked] (Dale R. Worley)
Date: Mon, 29 Aug 2016 14:49:08 -0400

TL;DR:  If the body for an emergencyCallData.eCall.MSD info package is
defined correctly, we can organize the data in an INFO request the same
way that we do in an INVITE request and still follow the info package
rules strictly.

After asking around, I have learned that my previous message on this
subject severely buried the lead:  The useful point followed a long
message example, which itself followed several pages of recap of the
points in question.  As far as I can tell, nobody had the stamina to
read that far, and in retrospect, I don't blame them.

So this time, I'm going recap my proposal and put the important points
*first*:

It it possible to define an info package for use by
draft-ietf-ecrit-ecall-11 that includes all of the Additional Data (RFC
7852) in a way that strictly follows the rules for info packages (RFC
6086), but also uses the same data format used by initial Additional
Data reporting.  This solves the dilemma that we have been discussing.

The key is to define the info package properly.  The info package
definition is:

    The body for an emergencyCallData.eCall.MSD info package is:

    - either an application/emergencyCallData.eCall.MSD+per (containing
      the MSD), or

    - a multipart body containing exactly:

        - exactly one application/emergencyCallData.eCall.MSD+per part
          (containing the MSD),

        - zero or more application/EmergencyCallData.DeviceInfo+xml
          parts (containing Additional Data), and

        - zero or one application/pidf+xml part (containing geolocation
          data).

This allows all of the information items that we want to carry in the
INFO message to be part of one info package, which is the body of the
INFO message.

In draft-ietf-ecrit-ecall-11 usage, all body parts will typically be
pointed to by a Geolocation or Call-Info header.

A typical example is this INFO request.  I've assembled the example by
inserting the Additional Data from an example in RFC 7852 into the
response INFO request in draft-ietf-ecrit-ecall-11:

      INFO urn:service:sos.ecall.automatic SIP/2.0
      To: urn:service:sos.ecall.automatic
      From: <sip:[email-masked]>;tag=9fxced76sl
      Call-ID: [email-masked]
      Call-Info: <cid:[email-masked]>;
                 purpose=emergencyCallData.eCall.MSD
      Call-Info: <http://wwww.example.com/hannes/photo.jpg>
                     ;purpose=icon,
        <http://www.example.com/hannes/> ;purpose=info,
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.ProviderInfo,
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.DeviceInfo
      Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
      Geolocation-Routing: yes
      Accept: application/sdp, application/pidf+xml,
              application/emergencyCallData.eCall.control+xml
      CSeq: 51862 INFO
      Info-Package: emergencyCallData.eCall.MSD
      Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
             SUBSCRIBE, NOTIFY, UPDATE
      Content-Disposition: info-package
      Content-Transfer-Encoding: binary
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...

      --boundary1
      Content-Type: application/emergencyCallData.eCall.MSD+per
      Content-ID: [email-masked]

           ...MSD in ASN.1 PER encoding goes here...

      --boundary1
      Content-Type: application/EmergencyCallData.DeviceInfo+xml
      Content-ID: <[email-masked]>
      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>
      <dev:EmergencyCallData.DeviceInfo
           xmlns:dev=
           "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
          ...
      </dev:EmergencyCallData.DeviceInfo>

      --boundary1
      Content-Type: application/EmergencyCallData.ProviderInfo+xml
      Content-ID: <[email-masked]>
      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>
      <pi:EmergencyCallData.ProviderInfo
         xmlns:pi=
            "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
          ...
      </pi:EmergencyCallData.ProviderInfo>
      --boundary1--

Note the absence of a Recv-Info header (which is forbidden in INFO
requests (RFC 6086 section 4.2.1).

Note the positioning of the Info-Package header as applying to the
entire body.

As indicated by the Info-Package header, the entire multipart body is
the body of the info package.  The info package body includes all of the
information contained in the body, including the MSD and the Additional
Data, thus strictly following RFC 6086.

Three of the Call-Info header values,
                 purpose=emergencyCallData.eCall.MSD
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.ProviderInfo
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.DeviceInfo
point to body parts within the info package that provide Additional
Data.

The Geolocation header points to an external application/pidf+xml
resource.  But it could contain a cid: URL pointing to an additional
application/pidf+xml body part.

Note that the layout of the body parts is the same as is used in an INFO
request containing Additional Data.  (Compare with the example in RFC
7852 section 7.)

This implies that the logic for inserting an additional Additional Data
part into an INFO request is essentially the same as the logic for
inserting it into an INVITE request.

Dale

---

From: Brian Rosen <[email-masked]>
Date: Mon, 29 Aug 2016 14:02:15 -0700

Verrrry interesting.

About the only part I don’t get is the Content Disposition of Info-Package on the whole body, no Content Disposition on the MSD, and then a different Content Disposition on the DeviceInfo block.

But I think it would be fairly easy to deal with if you were expecting it, which is what an implementation that handled eCall (and thus the emergencyCallData.eCall.MSD part) would do.

It’s clever, I will say that.

Brian

> On Aug 29, 2016, at 11:49 AM, Dale R. Worley <[email-masked]> wrote:
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Aug 2016 22:10:58 +0000

I may have missed something, but to me this seems more or less like what has already been discussed in ECRIT: associate the MSD inside an info package, but still use Call-Info to point to it.

As a side note, it's important to separate the *transport mechanism* defined in Additional Data (chapter 6 of RFC 7852), and the *data structures* (Device Information) defined in Additional Data. There is currently no requirement for ecall to support the data structures, and they are not mentioned/referenced in draft-ecall.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 30 August 2016 00:02
To: Dale R. Worley <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11

Verrrry interesting.

Brian

> defined correctly, we can organize the data in an INFO request the 
> same way that we do in an INVITE request and still follow the info 
> package rules strictly.
> 
> 
> the body of the info package.  The info package body includes all of 
> the information contained in the body, including the MSD and the 
> Additional Data, thus strictly following RFC 6086.
> 
> Note that the layout of the body parts is the same as is used in an 
> INFO request containing Additional Data.  (Compare with the example in 
> RFC
> 7852 section 7.)
> 
> This implies that the logic for inserting an additional Additional 
> Data part into an INFO request is essentially the same as the logic 
> for inserting it into an INVITE request.
> 
> Dale
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 29 Aug 2016 15:54:59 -0700

No, this really does return the MSD in an info block, but it also has the Additional Data header pointing to the body part that contains the MSD.

eCall itself doesn’t use the other structures, but we would like to see them in any emergency call, so showing how they would be carried is useful.

Brian

> On Aug 29, 2016, at 3:10 PM, Christer Holmberg <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 05:27:58 +0000

>No, this really does return the MSD in an info block, but it also has the >Additional Data header pointing to the body part that contains the MSD.

That’s what I said :)

And, how is that different from what is currently specified in draft-ecall-11?

Regards,

Christer

On Aug 29, 2016, at 3:10 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 30 August 2016 00:02
To: Dale R. Worley <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11

Verrrry interesting.

Brian

On Aug 29, 2016, at 11:49 AM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

draft-ietf-ecrit-ecall-11 that includes all of the Additional Data
(RFC

    Call-ID: [email-masked]<mailto:[email-masked]>

    --boundary1
    Content-Type: application/emergencyCallData.eCall.MSD+per
    Content-ID: [email-masked]<mailto:[email-masked]>

    --boundary1
    Content-Type: application/EmergencyCallData.DeviceInfo+xml
    Content-ID: <[email-masked]<mailto:[email-masked]>>
    Content-Disposition: by-reference;handling=optional

    --boundary1
    Content-Type: application/EmergencyCallData.ProviderInfo+xml
    Content-ID: <[email-masked]<mailto:[email-masked]>>
    Content-Disposition: by-reference;handling=optional

Dale

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Aug 2016 09:51:14 -0400

On 8/30/16 1:27 AM, Christer Holmberg wrote:
>
>>No, this really does return the MSD in an info block, but it also has
> the >Additional Data header pointing to the body part that contains the MSD.
>
> That’s what I said :)
>

Its different because of the nesting structure of the body parts, and 
their respective content-disposition values.

In this form the MSD has a c-d of by-reference, as it should. And yet it 
meets your objections because it is *part* of the info package body that 
has a c-d of info-package, as it should.

	Thanks,
	Paul

> Regards,
>
>
>
> Christer
>
>
>
>
>
>     On Aug 29, 2016, at 3:10 PM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     I may have missed something, but to me this seems more or less like
>     what has already been discussed in ECRIT: associate the MSD inside
>     an info package, but still use Call-Info to point to it.
>
>     As a side note, it's important to separate the *transport mechanism*
>     defined in Additional Data (chapter 6 of RFC 7852), and the *data
>     structures* (Device Information) defined in Additional Data. There
>     is currently no requirement for ecall to support the data
>     structures, and they are not mentioned/referenced in draft-ecall.
>
>     Regards,
>
>     Christer
>
>     To: Dale R. Worley <[email-masked] <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>
>     About the only part I don’t get is the Content Disposition of
>     Info-Package on the whole body, no Content Disposition on the MSD,
>     and then a different Content Disposition on the DeviceInfo block.
>
>     But I think it would be fairly easy to deal with if you were
>     expecting it, which is what an implementation that handled eCall
>     (and thus the emergencyCallData.eCall.MSD part) would do.
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Aug 2016 11:14:50 -0400

Whoops, a mistake on my part in the previous discussion.

It turns out that per RFC 6086, in an info package INFO request, the
Info-Package header is attached to the message (not to the body part
that is the info package contents), and the body part that is the info
package contents is identified by the header "Content-Disposition:
info-package".

It turns out that my example is correct, because it didn't use those
headers as I thought it did!

Brian Rosen <[email-masked]> writes:
> About the only part I don't get is the Content Disposition of
> Info-Package on the whole body, no Content Disposition on the MSD, and
> then a different Content Disposition on the DeviceInfo block.

Thanks for mentioning that.  I was wrong in my understanding of how
Info-Package and Content-Disposition are to be used in info package INFO
requests.  (See above.)

In re the Content-Disposition of the whole body, it is required to be
"info-package", because of RFC 6086 and that we're constructing the info
package so that the entire body is the contents thereof.

In re the Content-Disposition of the Additional Data parts, I've used
"by-reference", because that's what's shown in
draft-ietf-ecrit-ecall-11.  The draft seems to copy that from RFC 7852,
which is about how Additional Data is carried in INVITE.  That
references back to RFC 5621, which says that by-reference informs the
UAS that the body part can only be processed correctly in the context of
the reference to the body part, and warns the UAS not to process the
body part if the UAS can't find the reference.  In this case, the
reference is in the corresponding Call-Info header value.

In re the Content-Disposition of the MSD part, that's messier.  In a
non-multipart body, the MSD part is the whole body, and by RFC 6086, the
Content-Disposition must be "info-package".  But once the MSD part is
turned into a body part of a multipart, the "Content-Disposition:
info-package" must be removed from it.  We could just omit it, as in
this situation, the UAC knows that the UAS processes MSDs.

> It's clever, I will say that.

That's the goal, construct an implementation that satisfies all the
conflicting requirements.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Aug 2016 11:29:38 -0400

Christer Holmberg <[email-masked]> writes:
> what has already been discussed in ECRIT: associate the MSD inside an
> info package, but still use Call-Info to point to it.

> And, how is that different from what is currently specified in

It *is* "more or less" like draft-ietf-ecrit-ecall-11, but it has
differences, and those differences are critical to not violating RFC
6086.  (Which I gather is the entire point of this conversation.)

In particular what is allowed as a body for the
emergencyCallData.eCall.MSD info package is changed to also allow
multipart bodies, some of which parts can be Additional Data types.
Thus, we can move the Additional Data blocks *into* the info package
body.

BTW, the name of the package would better be "emergencyCallData.eCall"
than "emergencyCallData.eCall.MSD".

> structures* (Device Information) defined in Additional Data. There is
> currently no requirement for ecall to support the data structures, and
> they are not mentioned/referenced in draft-ecall.

That's true, but seems to be well-understood.

That fact does have a technical consequence, though:  The Additional
Data components need to have "Content-Disposition:
...;handling=optional" headers so that the callees know that if they
don't know how to process (a particular type of) Additional Data, the
request should be accepted.  But that's discussed in RRC 7852.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 17:25:28 +0000

Hi,

> It *is* "more or less" like draft-ietf-ecrit-ecall-11, but it has differences, and those differences are critical to 
> not violating RFC 6086.  (Which I gather is the entire point of this conversation.)
>
> In particular what is allowed as a body for the emergencyCallData.eCall.MSD info package is changed to also allow multipart bodies, 
> some of which parts can be Additional Data types. Thus, we can move the Additional Data blocks *into* the info package body.

Nothing prevents you from having a multipart body, with a SINGLE body inside. There is even an example of that in RFC 6086.

> That's true, but seems to be well-understood.

I just wanted to point it out, since you started to talk about the AD data structures.

> That fact does have a technical consequence, though:  The Additional Data components need
> to have "Content-Disposition:
> ...;handling=optional" headers so that the callees know that if they don't know how to process 
> (a particular type of) Additional Data, the request should be accepted.  But that's discussed in RRC 7852.

When you indicate support of an info package, you indicate that you support all MIME types associated with the info package.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 17:25:40 +0000

Hi,

>>> the Additional Data header pointing to the body part that contains the MSD.
>>
>> That's what I said :)
>>
> Its different because of the nesting structure of the body parts, and their respective content-disposition values.
>
> In this form the MSD has a c-d of by-reference, as it should. And yet it meets your objections because it is *part* of 
> the info package body that has a c-d of info-package, as it should.

It still uses Call-Info to define the semantics of content - THAT is my objection. You don't define the semantics within the info package description - you are only using an info package as a "cosmetic wrapper" for another mechanism.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 17:29:51 +0000

Hi,

...

> In re the Content-Disposition of the whole body, it is required to be "info-package", because of RFC 6086 and that we're 
> constructing the info package so that the entire body is the contents thereof.
>
> In re the Content-Disposition of the Additional Data parts, I've used "by-reference", because that's what's shown in 
> draft-ietf-ecrit-ecall-11.  The draft seems to copy that from RFC 7852, which is about how Additional Data is carried in 
> INVITE.  That references back to RFC 5621, which says that by-reference informs the UAS that the body part can only 
> be processed correctly in the context of the reference to the body part, and warns the UAS not to process the body part 
> if the UAS can't find the reference.  In this case, the reference is in the corresponding Call-Info header value.

...and that's the issue. When you use an info package, you define which MIME types are associated with the info package, and the semantics/context of those MIME types. There is no need for Call-Info.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 31 Aug 2016 11:56:16 -0400

Christer Holmberg <[email-masked]> writes:
> It still uses Call-Info to define the semantics of content - THAT is
> my objection. You don't define the semantics within the info package
> description - you are only using an info package as a "cosmetic
> wrapper" for another mechanism.

Not necessarily.  We could *define* the semantics of the body parts to
be due to their Mime types, and then say that in *this* usage, you also
provide the UAS with a hint in the form of Call-Info headers.

Really, the same thing comes up with the original INVITE.  The UAS can
tell from the Mime types how to handle the body parts, but RFC 7852
specifies that Call-Info headers must also be supplied.  If I'd been
commenting on that draft, I'd have asked why the redundancy.

But IMHO this is slicing hairs finer than even I am willing to go.  I
think we've got a solution that is within the rules of RFC 6086, even if
they are read strictly.  It solves all the practical problems.  And it
doesn't require much additional implementation work (beyond what is
needed for INVITEs) -- other than the question of how intermediaries
recognize which INFOs need to have Additional Data attached.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 16:21:09 +0000

Hi,

>Not necessarily.  We could *define* the semantics of the body parts to be due to their Mime types, and then
>say that in *this* usage, you also provide the UAS with a hint in the form of Call-Info headers.
>
>Really, the same thing comes up with the original INVITE.  The UAS can tell from the Mime types how to handle 
>the body parts, but RFC 7852 specifies that Call-Info headers must also be supplied.  If I'd been commenting on 
>that draft, I'd have asked why the redundancy.

In general, the MIME types alone don't always tell you everything about the semantics/context - that's one of the reason we did RFC 6086.

In INVITEs we don't use info packages, so one way to associate semantics/context with MIME bodies is using Call-Info.

>But IMHO this is slicing hairs finer than even I am willing to go.  I think we've got a solution that is within the rules of RFC 6086, even if they are read strictly.  It solves all the >practical problems. 

What practical problems? 

>And it doesn't require much additional implementation work (beyond what is needed for INVITEs) -- other than the question of how intermediaries 

Not sure I understand your issue regarding intermediaries.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 31 Aug 2016 16:17:57 -0400

Christer Holmberg <[email-masked]> writes:

>>think we've got a solution that is within the rules of RFC 6086, even
>>if they are read strictly.  It solves all the practical problems. 
>
> What practical problems? 

As far as I can see, we need a way of carrying the Additional Data, and
it would be useful to carry it in much the same way as it is carried in
the INVITE.  Are there others?

>>other than the question of how intermediaries recognize which INFOs
>>need to have Additional Data attached.
>

If I understand the processing correctly, the caller sends an INFO
request containing the control data block, but various intermediaries
between the caller and the callee add the Additional Data blocks.  In
order to get the mechanism to work correctly, the intermediaries need to
recognize the INFO requests to which they should add Additional Data
resends.  There needs to be a clear specification which INFO requests
get this processing and which don't, and that specification has to allow
for unanticipated future uses.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Aug 2016 16:32:13 -0400

> In general, the MIME types alone don't always tell you everything about the semantics/context - that's one of the reason we did RFC 6086.

+1

> In INVITEs we don't use info packages, so one way to associate semantics/context with MIME bodies is using Call-Info.

But call-info (with or without an attached body) wasn't defined solely 
for INVITE. It was defined for any message in which you have need to 
attach info described by one of the defined call-info purposes.

So, the UA can have logic that says: I'm sending a request, is there 
some call-info data that I should attach to it? And if the answer is 
yes, then it can do so in a consistent way.

It would be much more of a mess if it then had to consider what the 
method was, and special case how it attaches the information.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 20:46:37 +0000

Hi,

> As far as I can see, we need a way of carrying the Additional Data, and it would be useful to carry it in much the same way as it is carried in the INVITE.  Are there others?

People want to use the Call-Info header field in INFO because it is used in INVITE (and possibly other methods), but technically you don't need it in order to get things to work if you are using an info package.

> If I understand the processing correctly, the caller sends an INFO request containing the control data block, but 
> various intermediaries between the caller and the callee add the Additional Data blocks.  In order to get the 
> mechanism to work correctly, the intermediaries need to recognize the INFO requests to which they should 
> add Additional Data resends.  There needs to be a clear specification which INFO requests get this processing 
> and which don't, and that specification has to allow for unanticipated future uses.

In general, if intermediaries are going to add content to INFO, and if such information can only be added to specific INFO usages, the intermediaries will have to look at the Info-Package header field (and in some cases perhaps also look at the content) in order to figure out what the INFO is all about.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 20:53:14 +0000

Hi,

...

> So, the UA can have logic that says: I'm sending a request, is there some call-info data that I should attach
> to it? And if the answer is yes, then it can do so in a consistent way.
>
> It would be much more of a mess if it then had to consider what the method was, and special case how it attaches the information.

IF method == INFO
  Attach this way
ELSE
 Attach that way

It's not that difficult :)

There are much more complicated things that you have to do based on the method. For example, you need to check whether the method falls under certain race condition rules, you have to check whether a method somehow affects some SIP level properties etc. Adding the content to the message is the easy part :)

Regards,

Christer

>> And it doesn't require much additional implementation work (beyond 
>> what is needed for INVITEs) -- other than the question of how intermediaries recognize which INFOs need to have Additional Data attached.
>

---

From: <[email-masked]>
Date: Wed, 31 Aug 2016 22:50:05 +0000

Hi, 
Here are my 5 Cent.
You are still discussing the stuff. And you are not far from each other.
All want to have a workable solution.
>From one side I can follow Christer's approach to have the clear use of SIP mechanisms that should be followed.

But to be provocative, seen it from operator point of view I do not care what mechanism my application will use. If it is the "wrong" Call-Info Header approach (If it is really wrong you are still fighting) or the correct INFO-Package mechanism.
So if both is correctly used within the INFO and satisfy any rule written within the RFC's why not.
It will not harm the core implementation of SIP.

For me it looks more complex for an application to look on two mechanisms to identify the content of the MIME and the INFO Package. Also looking on the processing it will be more complex and resource consuming. 

>From pure operational perspective (where are network operators are interested in) at least the Call-Info header can be used as trigger within the tracing tool to track the eCall relevant messages containing MSD information. Alone from that perspective I would like to keep it within the INFO.

So looking into the draft I personally do not see anything what is contradicting to that what was said until now. 

But if people see phrases which needs progress why not point to them and propose improved text?
But the we should shift the discussion back to ecrit. 

Thank you and Best Regards

Roland

Mit freundlichen Grüßen
 
Roland Jesske
Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Pflichtangaben gemäß § 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.