Could somebody please explain the logic of Message-ID created by MS Outlook? especially this part “D45A2C0A.EB29”
User-Agent: Microsoft-MacOutlook/14.6.9.160926
Date: Tue, 22 Nov 2016 17:08:26 -0600
Subject: Video playback error
From: “AAAAAAAAAAAA AAAAA, BBBBB (BBBBB AAAAAA)”
<bbbbb.aaaaa#my.domain.com>
To: “ZZZ, YYYY P (YYYY ZZZZ)” <yyyy.zzz#my.domain.com>
Message-ID: <D45A2C0A.EB29%bbbbb.aaaaa#my.domain.com>
Thread-Topic: Video playback error
MIME-Version: 1.0
Content-type: multipart/mixed;
boundary="B_3563051944_9433913"
RFC2392 confirms that 'both message-id and content-id are required to be globally unique. 'My question is specific for MS Outlook. I would like to know, what kind of logic used by MS Outlook to create the unique number? Can I extract time/date from that Hexadecimal number?
According to RFC2822 - Internet Message Format, the Message ID should be unique for each instance of the message. It's considered optional and how the MESSAGE-ID field is created is up to the server:
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the message identifier is guaranteed by the host that
generates it (see below). This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A message
identifier pertains to exactly one instantiation of a particular
message; subsequent revisions to the message each receive new message
identifiers.
Note: There are many instances when messages are "changed", but those
changes do not constitute a new instantiation of that message, and
therefore the message would not get a new message identifier. For
example, when messages are introduced into the transport system, they
are often prepended with additional header fields such as trace
fields (described in section 3.6.7) and resent fields (described in
section 3.6.6). The addition of such header fields does not change
the identity of the message and therefore the original "Message-ID:"
field is retained. In all cases, it is the meaning that the sender
of the message wishes to convey (i.e., whether this is the same
message or a different message) that determines whether or not the
"Message-ID:" field changes, not any particular syntactic difference
that appears (or does not appear) in the message.
Related
I’m developing an Messages extension. When it comes time to send a message, I want it to show up as something like: “Jeff sent a message.”
However, the MSConversation APIs only give us identifiers. When you use these identifiers in the MSMessage layout, it’s supposed to convert them to a name. When I attempt to do this, I see that it does indeed convert the identifier, but it converts it to the phone number of the participant rather than their name.
In other words, the following:
layout.caption = "$\(uuidOfTheParticipant) sent a message"
Shows up as “+15555551234 sent a message”. I’d like it to show a name instead of the phone number.
I searched the documentation to verify that this should be the behavior. I found out it was documented in the WWDC 2016 session 224 video. This was called “iMessage Apps and Stickers Part 2”. The video has been taken down since, so I had to rely on this transcript, where it states:
similarly, you can use these identifiers in the text passed to the Messages sumamaryText. When Messages displays the UI for the bubbles with this type of formatting in their text, it will replace the identifiers with the contact name of the person that their identifier maps to.
In both cases, it sounds like the name of the participant should be showing up rather than their phone number.
I tried updating my contact’s number to look exactly like the one that’s being output (I.e. “+1” in front), but it’s still showing the phone number rather than the name.
Does the API no longer show names, or am I doing something wrong?
Using Microsoft Graph, how can I determine which message an outgoing message is a reply to?
The internetMessageHeaders property is not available for items in the Sent Items folder of mailboxes (using the Graph API, at least -- they are available using EWS or IMAP). If it were, I'd look for the in-reply-to header. In the absence of this, is there something in the standard Graph message properties that will tell me this?
You can check the "Subject" or "bodyPreview" to check if the content contains "RE:", if the answer is yes, the message is reply to.
You can group the message by conversationId and then order by lastModifiedDateTime. This way can check if the message is the original one, if it is not ,it will be reply-to/follow-up one.
Get the message list first(/me/messages or /users/{id | userPrincipalName}/messages and so on), and then foreach the message id to call reply api(/users/{id | userPrincipalName}/messages/{id}/reply and so on). The result in the reply is a reply to.
To Test this, you can use the Graph Explorer first and then paste the JSON to a JSON viewer tool. For further use, you need to use net/java and so on to handle.
API reference: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/message
https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/message_reply
We've encountered something we haven't seen before. Looking through the HL7 documentation/standards has left me scratching my head.
We are sending in a standard outbound report message (ORU^R01). It contains MSH, PID, OBR, and OBX segments. In all other cases where we've implemented our system, we get back an acknowledgement that looks like this:
MSH|^~\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS||ACK|MESSAGEID|T|2.5\
MSA|AA|MESSAGEID|ACK
However, there is a new system that is returning this:
MSH|^~\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS||ORU^R01|MESSAGEID|T|2.5\
MSA|AA|MESSAGEID|ACK
Notice MSH-9 in the ack. It isn't ACK it is the ORU^R01. Now, we use HAPI to process HL7 messages and it doesn't like this response. I can't tell if this conforms to the HL7 spec (2.5).
Any ideas?
To expand on my previous comment, I read the HL7 v2.5 standard a little bit.
According to my understanding the MSH-9 field contains three components defines as follows:
Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
Each of those has a corresponding table of legal values: HL7 Table 0076 - Message type, HL7 Table 0003 - Event type and HL7 Table 0354 - Message structure.
Looking at these tables, I would say that an ORU message should have an MSH-9 value of ORU^R01^ORU_R01and an acknowledgement should be ACK^R01^ACK.
Therefore the new system seems to be breaking the standard and HAPI is right to reject it, if it tries to validate the message against the standard.
The main point here is, that the receiving application should be able to decide, where to route and what to do with the message only looking at the MSH fields, without going in to following segments. Therefore you cannot put into the acknowledgment message the exact same MSH that the incoming message had, because it would not identify then the header does not match the message structure.
I mainly referenced HL7 Standard version 2.5 Chapter 2 for this answer.
I am pretty new to Cumulocity and I am trying to get data into the platform from my own device using mqtt and the smartrest templates. I can get data in using the static templates but they only support certain data types. I am struggling to create the appropriate smartrest template in the UI and the documentation doesn't go into much detail.
I get that the template name goes in the MQTT topic (or selected on login as part of the username) in s/ut/template_name and the messageId of the messages in the template get matched to the first CSV field of the MQTT publish payload. What I don't get is the template terminology. In the UI I choose API->Measurement and Method->POST and I am presented with required values $.type and $.time. My questions:
Is $.type the "measurement fragment type" name or do I have to make it "c8y_CustomMeasurement"? Can I call it whatever I want?
$.time has a value field. Is this the default value if one is not supplied in the publish?
I assume I need to add a numerical value in the optional API values. To link it to the value of the data point should I make the key "c8y_CustomMeasurement.custom.value"?
Am I way off base here?
Every time I publish to my own smartrest template the server drops the connection so I assume its an error in my template setup but I don't see a way of accessing debug messages (also nothing is published back to me on s/e or s/dt).
For the sake of an example, lets say I wish to publish a unitless, timestamped pulse count with payload format "mId,ts,value" with example data "p01,'2017-07-17 12:34:00',1234"
What you wrote so far is mostly correct just to be a bit more precise:
The topic is s/uc/template_id (not the template name, this is just a label)
The $.type refers to the 'type' fragment in the measurement JSON. It is a free text field
In 99% of cases you want to leave the $.time empty. If you set something here it is not the default but fixed to that timestamp and you cannot change it when using the template. If you leave it empty and still not send something in
Example: p01,2017-07-17T12:34:00,1234 (no quotes arounf timestamp and ISO8601 format
Example without sending time: p01,,1234 (sending empty string as time results in server time beeing set. The template is the same)
Hope these points help you to find you issue
The way I have understood idempotency thus far is basically: If I send 10 identical PUTs to a server the resulting additional resources created will be identical to if I had sent a single PUT statement.
What I take this to mean is that the following implementation would adhere to this:
[AcceptVerbs(HttpVerbs.Put)]
ContentResult User(){
//parse XML that was sent to get User info
//User has an e-mail address which is unique to the system
//create a new user in the system only if one for this e-mail address does not exist
return Content(something, "text/xml");
}
There now if I sent 10 PUTs with XML for User data and they all contain the same e-mail address, only one user will be created.
However, what if they send 10 requests (for whatever reason) and they are all different, but the e-mail is the same. If the first request doesn't make it through then the data of the 2nd request will be used to create the user, and the following 8 requests will be ignored. Is there a flaw here? Or should I literally only ignore requests that are explicitly identical in every way and instead send back an error saying the user already exists if they use the same e-mail address?
Also, what kind of response should be sent from a such PUT statement? Info about the user? Maybe an ID to manipulate them with other API calls? Or perhaps it should just say "success" or "fail: [error details]"?
Your question doesn't reveal the URL where the PUT request is sent to. This is actually very important as it is not the email address within the XML data that dictates whether a new resource is created or an old one updated but the URL that you are sending the request to.
So, if you send PUT to /users/jonh.doe#foo.com/ it either creates the user john.doe#foo.com or updates it if it was already in the system.
Similaraly, if you send PUT to /users/123/ (using id instead of email) it will create or update user 123. However, in this case if the email has to be unique and somebody sends PUT /users/456/ and within that XML is the same email as what the user 123 already has, you have to respond with 409 Conflict.
If the user already exists with the same email address, then the 2nd and subsequent PUT operations should update the data for that resource. The success or failure should be communicated in the status code. If the update succeeds, respond with "200 OK", or "204 No Content"; you can return some information, but don't expect caches to store it as if it were the new representation you would obtain from a GET. If you do not intend for that resource to ever accept a PUT operation other than the first one, then respond instead with "405 Method Not Allowed", with an explanation in the response body. Use "409 Conflict" (again, with an explanation in the response body) if the submitted representation might replace the resource, but can't because it's particular fields cannot be reconciled with the existing state.