What's the difference between the various printer connections?
I'm installing a new printer and I'm given 4 connection options.
- AppSocket/JetDirect network printer via DNS-SD
- LPD network printer via DNS-SD
- IPP network printer via DNS-SD
- AppSocket/HP JetDirect
Which one should I choose?
It's a Samsung CLP-320 if it makes a difference.
printing samsung
edited Jun 9 '14 at 14:09
bain
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
add a comment |
I'm installing a new printer and I'm given 4 connection options.
- AppSocket/JetDirect network printer via DNS-SD
- LPD network printer via DNS-SD
- IPP network printer via DNS-SD
- AppSocket/HP JetDirect
Which one should I choose?
It's a Samsung CLP-320 if it makes a difference.
printing samsung
edited Jun 9 '14 at 14:09
bain
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
2
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52
add a comment |
I'm installing a new printer and I'm given 4 connection options.
- AppSocket/JetDirect network printer via DNS-SD
- LPD network printer via DNS-SD
- IPP network printer via DNS-SD
- AppSocket/HP JetDirect
Which one should I choose?
It's a Samsung CLP-320 if it makes a difference.
printing samsung
edited Jun 9 '14 at 14:09
bain
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
I'm installing a new printer and I'm given 4 connection options.
- AppSocket/JetDirect network printer via DNS-SD
- LPD network printer via DNS-SD
- IPP network printer via DNS-SD
- AppSocket/HP JetDirect
Which one should I choose?
It's a Samsung CLP-320 if it makes a difference.
printing samsung
printing samsung
edited Jun 9 '14 at 14:09
bain
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
edited Jun 9 '14 at 14:09
bain
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
edited Jun 9 '14 at 14:09
bain
9,06322942
edited Jun 9 '14 at 14:09
bain
9,06322942
edited Jun 9 '14 at 14:09
bain
9,06322942
9,06322942
asked Sep 15 '12 at 1:18
user63138
86113
asked Sep 15 '12 at 1:18
user63138
86113
asked Sep 15 '12 at 1:18
user63138
86113
86113
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
2
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52
add a comment |
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
2
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
2
2
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52
add a comment |
3 Answers
3
active
oldest
votes
http://www.cups.org/articles.php?L193+TFAQ+Q
Both the LPD and JetDirect/AppSocket protocols can be used over the Internet today, however neither of these protocols provides authentication services, access control, and all of the document management and formatting (including printer-specific commands) must be handled by the machine sending the document. If you don't know what kind of printer is on the receiving end you may not be able to successfully print your document!
This was back in 2005 so things might have changed
answered Sep 15 '12 at 4:27
waspinator
2,11251935
add a comment |
Since that printer is USB the answer is none of them, as they are all for network printers. When you plug the printer in on USB it should be detected automatically by the printer setup tool.
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
add a comment |
@waspinator's answer of the question goes a long way already (I upvoted it). But here are some additional details...
The main advantage of IPP over JetDirect/AppSocket are these:
AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).
AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it (quite long ago) and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.
IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new 'IPP Everywhere' Standard.
With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.
With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.
IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...
With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).
IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)
In the specific case of your printer, though: some vendors/models have buggy IPP implementations, and they may not work well, while AppSocket printing to the same model may work flawlessly. Just test it with IPP, and keep using it if it works fine. If not, revert to AppSocket (or USB).
answered Dec 15 at 17:48
Kurt Pfeifle
993710
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f187934%2fwhats-the-difference-between-the-various-printer-connections%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
http://www.cups.org/articles.php?L193+TFAQ+Q
Both the LPD and JetDirect/AppSocket protocols can be used over the Internet today, however neither of these protocols provides authentication services, access control, and all of the document management and formatting (including printer-specific commands) must be handled by the machine sending the document. If you don't know what kind of printer is on the receiving end you may not be able to successfully print your document!
This was back in 2005 so things might have changed
answered Sep 15 '12 at 4:27
waspinator
2,11251935
add a comment |
http://www.cups.org/articles.php?L193+TFAQ+Q
Both the LPD and JetDirect/AppSocket protocols can be used over the Internet today, however neither of these protocols provides authentication services, access control, and all of the document management and formatting (including printer-specific commands) must be handled by the machine sending the document. If you don't know what kind of printer is on the receiving end you may not be able to successfully print your document!
This was back in 2005 so things might have changed
answered Sep 15 '12 at 4:27
waspinator
2,11251935
add a comment |
http://www.cups.org/articles.php?L193+TFAQ+Q
Both the LPD and JetDirect/AppSocket protocols can be used over the Internet today, however neither of these protocols provides authentication services, access control, and all of the document management and formatting (including printer-specific commands) must be handled by the machine sending the document. If you don't know what kind of printer is on the receiving end you may not be able to successfully print your document!
This was back in 2005 so things might have changed
answered Sep 15 '12 at 4:27
waspinator
2,11251935
http://www.cups.org/articles.php?L193+TFAQ+Q
Both the LPD and JetDirect/AppSocket protocols can be used over the Internet today, however neither of these protocols provides authentication services, access control, and all of the document management and formatting (including printer-specific commands) must be handled by the machine sending the document. If you don't know what kind of printer is on the receiving end you may not be able to successfully print your document!
This was back in 2005 so things might have changed
answered Sep 15 '12 at 4:27
waspinator
2,11251935
answered Sep 15 '12 at 4:27
waspinator
2,11251935
answered Sep 15 '12 at 4:27
waspinator
2,11251935
answered Sep 15 '12 at 4:27
waspinator
2,11251935
2,11251935
add a comment |
add a comment |
Since that printer is USB the answer is none of them, as they are all for network printers. When you plug the printer in on USB it should be detected automatically by the printer setup tool.
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
add a comment |
Since that printer is USB the answer is none of them, as they are all for network printers. When you plug the printer in on USB it should be detected automatically by the printer setup tool.
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
add a comment |
Since that printer is USB the answer is none of them, as they are all for network printers. When you plug the printer in on USB it should be detected automatically by the printer setup tool.
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
Since that printer is USB the answer is none of them, as they are all for network printers. When you plug the printer in on USB it should be detected automatically by the printer setup tool.
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
answered Oct 19 '12 at 20:11
Alistair Buxton
4,96132453
4,96132453
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
add a comment |
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
2
2
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
That's a useless answer. Even if the OP got the model wrong (maybe missed the 'N'), the question is about network connections to printers. They wouldn't even see those options if it was a USB printer.
– waspinator
Oct 23 '12 at 0:50
1
1
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
Not true. They will see these options with a USB printer because the printer settings dialog displays them while detecting printers, rather than displaying a message such as "detecting printers". This is confusing and leads the user to think that they must manually enter printer details as has happened here.
– Alistair Buxton
Oct 30 '12 at 10:06
3
3
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
fine. that doesn't answer the question though. what is the difference between them?
– waspinator
Nov 3 '12 at 1:11
1
1
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
Correct. It answers the question "which one should I choose?"
– Alistair Buxton
Nov 3 '12 at 18:24
2
2
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
The point is that they noted the model number as an aside, but were asking about the choice of protocol option. So in addition to waspinator's input, it seems to me that they might be simply adding a new printer to their laptop config, which has already been made into a network printer by being connected via USB to some other system and shared by that system over the intranet. And it certainly is possible to connect to a USB printer that way, over the network.
– nealmcb
Mar 4 '16 at 22:48
add a comment |
@waspinator's answer of the question goes a long way already (I upvoted it). But here are some additional details...
The main advantage of IPP over JetDirect/AppSocket are these:
AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).
AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it (quite long ago) and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.
IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new 'IPP Everywhere' Standard.
With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.
With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.
IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...
With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).
IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)
In the specific case of your printer, though: some vendors/models have buggy IPP implementations, and they may not work well, while AppSocket printing to the same model may work flawlessly. Just test it with IPP, and keep using it if it works fine. If not, revert to AppSocket (or USB).
answered Dec 15 at 17:48
Kurt Pfeifle
993710
add a comment |
@waspinator's answer of the question goes a long way already (I upvoted it). But here are some additional details...
The main advantage of IPP over JetDirect/AppSocket are these:
AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).
AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it (quite long ago) and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.
IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new 'IPP Everywhere' Standard.
With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.
With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.
IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...
With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).
IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)
In the specific case of your printer, though: some vendors/models have buggy IPP implementations, and they may not work well, while AppSocket printing to the same model may work flawlessly. Just test it with IPP, and keep using it if it works fine. If not, revert to AppSocket (or USB).
answered Dec 15 at 17:48
Kurt Pfeifle
993710
add a comment |
@waspinator's answer of the question goes a long way already (I upvoted it). But here are some additional details...
The main advantage of IPP over JetDirect/AppSocket are these:
AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).
AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it (quite long ago) and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.
IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new 'IPP Everywhere' Standard.
With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.
With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.
IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...
With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).
IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)
In the specific case of your printer, though: some vendors/models have buggy IPP implementations, and they may not work well, while AppSocket printing to the same model may work flawlessly. Just test it with IPP, and keep using it if it works fine. If not, revert to AppSocket (or USB).
answered Dec 15 at 17:48
Kurt Pfeifle
993710
@waspinator's answer of the question goes a long way already (I upvoted it). But here are some additional details...
The main advantage of IPP over JetDirect/AppSocket are these:
AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).
AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it (quite long ago) and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.
IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new 'IPP Everywhere' Standard.
With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.
With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.
IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...
With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).
IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)
In the specific case of your printer, though: some vendors/models have buggy IPP implementations, and they may not work well, while AppSocket printing to the same model may work flawlessly. Just test it with IPP, and keep using it if it works fine. If not, revert to AppSocket (or USB).
answered Dec 15 at 17:48
Kurt Pfeifle
993710
answered Dec 15 at 17:48
Kurt Pfeifle
993710
answered Dec 15 at 17:48
Kurt Pfeifle
993710
answered Dec 15 at 17:48
Kurt Pfeifle
993710
993710
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f187934%2fwhats-the-difference-between-the-various-printer-connections%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Who would want unsecure connections? It's like asking someone if they want to drive a safe car.
– waspinator
Oct 23 '12 at 0:51
2
@waspinator: I want unsecured connections, under certain circumstances, for example HTTP. I also prefer some unsecured connections on my LAN, specifically when security requires unacceptable complication or overhead... Assuming the service is only available from inside my LAN, and nothing confidential is transmitted over-the-wire. However when security doesn't impose significant complexity or overhead, then I would prefer the secured connection.
– J. M. Becker
Mar 6 '13 at 18:54
@TechZilla: the web is slowly moving from HTTP to HTTPS. I feel regular users shouldn't have to worry about any complications or overhead; it should be secure, and it should just work. I don't remember having to do anything when google or facebook switched to HTTPS. Ubuntu should work on making the system as secure as possible without any user intervention. In the meantime, do you know which one of these is safest to use?
– waspinator
Mar 8 '13 at 21:52