Per RFC 2046:
The inclusion of a "References" field in the headers of the second and subsequent pieces of a fragmented message that references the Message-Id on the previous piece may be of benefit to mail readers that understand and track references. However, the generation of such "References" fields is entirely optional.
I see this. It does not explicitly mention how it is usually used in practice. Does anybody have a summary of common email clients and online email service providers (e.g., Gmail) on how this is implemented in practice?
Related
From what I've read, every Message-ID must be unique, however it is possible to create repeated Message-IDs if we force the header with a fixed value. So I don't understand what the point of them saying that the Message-ID should be unique, but they are very easy to create duplicates. If they can easily be generated by anyone with a little reading and basic programmatic knowledge, why do Message-IDs exist and what are they used for, which I can easily duplicate?
Short answer: For threading in email clients.
The message-id header is defined in RFC 2822:
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers
The message ID is used to show which message is a reply to which other message, for example. That way mail clients can show a tree of emails with their replies even if other things like the Subject don't change. (Counting leading Re:s of the subject line would be a bad way to determine ancestors and children: not every mail client adds them, and some use language specific ones.)
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4
in conjunction with the References and In-Reply-To fields, mail clients use Message-ID to organize multiple messages into threads.
https://en.wikipedia.org/wiki/Message-ID
and at least some clients will consider two messages with the same ID to be the same thing and discard one of them.
If you're in a microservice architecture where a business user needs admin capabilities to add and remove items from a database for that service and wants a message saying the operations were successful or not, so not just a 201 response.
When you are returning a response for a POST and DELETE what is the preferred industry practice? To send back a string message saying it was successful or not? Or would it be better to have a new value object with a member String message, and getter/setter returned, that can be serialized and returned into the response the user will see?
Is there a preferred approach, or does it not matter?
It depends.
The message-body of an HTTP response is, semantically, a message.
200 OK
Content-Type: text/plain
IT WORKED
Using plain text for messages is fine when the message recipient is a human, because humans are semantically flexible. A human familiar with American English is going to understand that message, and if you later decide to change it to a less shouty spelling, the human recipient will probably be able to work it out.
When machines are reading the message, plain text becomes less satisfactory -- the problem comes when you need to change the message, and without structure the machines have a difficult time finding what they need.
If you look at the example above, the headers, including the status-line, conform to a schema designed some 20 years ago. HTTP clients know how to parse the headers, and identify headers that they care about, and so on, because there is a well specified pattern to how information is encoded into the header of the response.
In the short term, you could define a schema where "IT WORKED" is one of the possible responses, and everybody could write their programs in accordance with that schema.
But when you need to extend the schema, to include more information? Can you satisfy your future requirements without breaking old clients?
On the other hand, if it is inexpensive to upgrade all of the clients (because they are all under your direct control?) then maybe you don't need an extensible message schema yet.
For a resource that will be deleted, ultimately with a soft delete (isDeleted flag), I am looking to provide a reason to store along with the resource for audit purposes.
The options I have encountered don't feel correct.
Custom HTTP Header
DELETE with Body
I have also considered instead using a PUT, but the content I would be putting is different from what makes up the resource on a typical update.
Which method makes the most sense from a RESTful perspective ?
DELETE with a body is wrong, in that it doesn't respect the semantics of the uniform interface defined in the HTTP specification.
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.
Note that the spelling used here is the same as that of a payload for a GET request.
Semantically, DELETE is the right choice; soft vs hard delete is "beyond the scope of the specification", which is to say it is an implementation choice.
But communicating the "reason" gives you two problems to solve. One is where to put that reason, and the answer is, of course, to use a header.
New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.
You can look through the message-headers registry to see if there is a close match to your requirements, but failing that you would define one of your own.
The second problem is figuring out how to communicate with the client so that it knows to use the header field. The most common approach today is to just write the header into the description of the API, but that's not quite REST.
The REST answer is that your hypermedia specification describes how the server might communicate to the client which headers are important, and what data should be put there. Imagine an HTML form with a "field-value" input control, and you've got the right idea.
Not many API bother to do it that way.
PUT is an intriguing choice; there's nothing in the rules that says that a resource can have only one content type, or that an endpoint must accept only one content type.
For instance, RFC 7807 defines application/problem+json, a simple representation for reporting issues from the server. But there's no reason that you couldn't PUT an application/problem+json representation to a resource to induce a soft delete.
This specification gives you both a title and a details element to play with, so the client has room to work.
Of course, it doesn't have to be application/problem+json -- you can specify a more suitable media type of your own design.
Again, you have similar problems to the using delete with a custom header: how does the client discover that your resources support put deletes?
Mail user agents usually display threads of Emails by chaining messages together according to the In-Reply-To and References header fields that contain the Message-IDs of other messages. Although a mail usually only replies to one other message, it may be the case that one message answers multiple others. The standard allows multiple entries in both fields. What can I expect when I send an email that References or is In-Reply-To multiple IDs this way?
Is it good practice to do so?
Does it confuse widespread MUAs?
Is there any common ground on how to display such a message in a
threaded view?
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields. If there is no "Message-ID:" field in
any of the parent messages, then the new message will have no "In-
Reply-To:" field.
Technically there COULD be a reason where you would reply to multiple emails and it would be valid to place multiple message ids in the In-Reply-To header. I can’t think of any program that actually supports this. As to MUAs they won’t care the delivery that the MUA cares about is the To, Cc, Bcc headers.
The In-Reply-To header and References header would control how threads are displayed. Not sure if any mail clients would have an issue handling the multiple In-Reply-To headers. 99% of the time there would only be a single message ID in the In-Reply-To header. So it’s feasible mail applications won’t support it. However they would support the additional reference entries. And this shouldn’t pose an issue.
I am developing a SIP client. I understand SIP requests and SIP responses but, in SIP messages, how are the call id and branch tags generated? RFC3261 does not specify this.
The Call-ID header value can be anything you want but does need to be unique in order to avoid requests getting classified as duplicates.
THe branch parameter on a Via header needs to start with the magic cookie value of z9hG4bK and must also be unique to avoid the request getting classified as a duplicate. For SIP Proxy's wanting to do loop detection there is also the guideline in the RFC in section 16.6 point 8 which details factors to take when constructing the branch parameter value.
Your wording is difficult to understand. I'm going to assume you want to know how a UAC should generate a Call-ID or how a UAC or proxy server should generate a branch parameter.
The only requirement for Call-ID is that it should be unique. It is often in the form of a unique token + "#" + a host name like email's Message-ID, but it doesn't have to be. It can be just a unique token. The unique token can be anything that is reasonably certain to be unique. In order to avoid divulging private information you can just make it pseudorandom or a cryptographic hash of private unique information (time, process ID, etc...)
Similarily, the branch parameter is just a unique token, but note that it has to start with z9hG4bK as specified in the RFC.
Why re-invent the wheel?
There are open source SIP projects and their implementation may inspire you.
You didn't mention what programming language you use. So I assume you can read C code.
Get the source code of kamailio server. The implementation of Call-ID is in kamailio-4.0.x/modules/tm/callid.c. I believe you are smart and can find out about branch tags yourself :o)