Property talk:P1641

Latest comment: 6 months ago by BEANS X2 in topic Planned deprecation of of (P642)


default communication endpoint in TCP, UDP, or other transport protocol
Descriptionnumber of communication endpoint in TCP or UDP protocol
Representsport (Q858321), Service Name and Transport Protocol Port Number Registry (Q30335969)
Data typeQuantity
Template parameterPort
According to this template: communication protocol (Q132364) (communication protocol)
According to statements in the property:
communication protocol (Q132364) or software (Q7397)
When possible, data should only be stored as statements
Allowed values
According to this template: 0 <= port <= 65535
According to statements in the property:
0 ≤ 𝓧 ≤ 65,535
When possible, data should only be stored as statements
Allowed unitsnot applicable
ExampleSimple Mail Transfer Protocol (Q160453) → 25
See alsoIANA service name (P5814), connector (P2935)
Proposal discussionProposal discussion
Current uses
Main statement39899.7% of uses
Qualifier10.3% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
Type “communication protocol (Q132364), software (Q7397): item must contain property “instance of (P31)” with classes “communication protocol (Q132364), software (Q7397)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1641#Type Q132364, Q7397, SPARQL
Range from “0” to “65535”: values should be in the range from “0” to “65535”. (Help)
List of violations of this constraint: Database reports/Constraint violations/P1641#Range, hourly updated report
  Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1641#allowed qualifiers, SPARQL
Units: “novalue”: value unit must be one of listed. (Help)
List of violations of this constraint: Database reports/Constraint violations/P1641#Units, hourly updated report
Required qualifier “protocol (P2700): this property should be used with the listed qualifier. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1641#mandatory qualifier, SPARQL
Integer: values should be integers (ie. they shouldn't have a fractional part) (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1641#integer, SPARQL
Scope is as main value (Q54828448): the property must be used by specified way only (Help)
List of violations of this constraint: Database reports/Constraint violations/P1641#Scope, hourly updated report, SPARQL

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Split into TCP port and UDP port edit

This property should either be split into a TCP port and a UDP port property or have an associated protocol qualifier (this first would seem more natural to me). —Ruud 17:03, 10 December 2014 (UTC)Reply[reply]

@Ruud Koot: qualifier TCP only, UDP only, officially both, and default "dunno, but at least TCP", would that do? And how could it be arranged? –Be..anyone (talk) 05:25, 29 March 2015 (UTC)Reply[reply]
Also, how can we differentiate between when a protocol uses multiple port simultaneously (e.g. FTP) versus when a protocol can use a number of alternative ports (e.g. HTTP)? —Ruud 17:07, 10 December 2014 (UTC)Reply[reply]
Implementation details or common practices (not limited to "best current" ;-) aren't a problem of this property, IIRC HTTP is officially 80, 79 was gopher, and other numbers such as 8080 are just made up. For FTP it's similar, one well-known port at the start, later using a random port at the server for the control channel, plus data port(s). Maybe "well-known" could be a subset (subclass?) of 0..65535 for better constraints. And maybe a "specified in RFC" property with numeric values—at the moment RFC 6335—would help for quick plausibility checks. –Be..anyone (talk)
As said in RFC 6335, port may be assigned for TCP, UDP, STCP or DCCP protocol (the UDP-Lite assignments are same with UDP). It will be useful add qualifier of (P642) to property values when needed. DrSauron (talk) 06:23, 29 March 2015 (UTC)Reply[reply]

bogus +/-1 edit

Please get rid of +/-1 for port numbers, e.g., "Freeciv" (Q424271) should show the official 5556, HTTP (Q8777) should show 80, etc. There's an authority control (IANA), I tried to add an external reference for the claimed port, but that didn't work (unusable "save" button). –Be..anyone (talk) 18:30, 9 January 2015 (UTC)Reply[reply]

Another editor managed to fix this on Q424271, so that problem is either entirely on my side, or only a tricky UI issue, not a poblem with the "port" property. –Be..anyone (talk) 12:52, 20 March 2015 (UTC)Reply[reply]
You can enter integer value as "5556+-0", and it will be saved as "5556" without annoying "±1". DrSauron (talk) 20:27, 26 March 2015 (UTC)Reply[reply]
The real solution would be to change the data type to ‘string’, which is more fitting for port numbers, just be for other numeric values such as telephone numbers, plates, or any other numeric identifier. Gallaecio (talk) 07:11, 15 May 2016 (UTC)Reply[reply]
Due to changes in the Wikidata engine, ±0 can be safely removed from now. DrSauron (talk) 19:56, 30 January 2017 (UTC)Reply[reply]

missing authority edit

The "add statement" feature doesn't support "authority" or "registry" with value IANA (Q416583), is that as it should be? –Be..anyone (talk) 18:38, 9 January 2015 (UTC)Reply[reply]

Maybe it could be handled as related property (P1659) IANA (Q416583) until somebody finds or creates a better "under the official authority of" property. –Be..anyone (talk) 04:59, 29 March 2015 (UTC)Reply[reply]

instance of edit

If it's not known as instance of (P31) communication protocol (Q132364) it should be still a part of (P361) client-server (Q146813) applications based on Transmission Control Protocol (Q8803) and/or User Datagram Protocol (Q11163), which does not exactly help for the currrent list of six constraint violations. One pftp (Q1554264) item is an instance of (P31) client (Q528166), and that's a part of (P361) client-server (Q146813). Maybe some instance of (P31) video game (Q7889) with game mode (P404) multiplayer game (Q209075) should be a part of (P361) client-server (Q146813) applications to get rid of more violations. –Be..anyone (talk) 04:22, 29 March 2015 (UTC)Reply[reply]

Constraints can have multiple choices in a list. Maybe we should {{Constraint:Type|classes=Q15836568,Q40056,Q1371279,Q1640628|relation=instance}} so that it might be valid for computer network protocol (Q15836568), computer program (Q40056), server software (Q1371279), network service (Q1640628). Can anyone think of something that is instance of (P31)communication protocol (Q132364) that would have a port (P1641) yet not be instance of (P31)computer network protocol (Q15836568)? --Closeapple (talk) 02:04, 4 June 2015 (UTC)Reply[reply]

Port should have qualifier P642 with protocol edit

I'm adding {{Constraint:Qualifiers|list={{P|642}}}} as a constraint. port (P1641) should always have at least of (P642) qualifier with a subclass/instance of computer network protocol (Q15836568): common ones would be Transmission Control Protocol (Q8803), User Datagram Protocol (Q11163); less common would be Datagram Congestion Control Protocol (Q1049960), Scalable TCP (Q7429669). Example of a proper claim:

Without a qualifier, a mere number is somewhat meaningless; Ruud implied this in the #Split into TCP port and UDP port section above. It's a bit like giving a house number without knowing the street or town. (Maybe splitting would make sense; but would we need one for rare protocols too?) --Closeapple (talk) 02:04, 4 June 2015 (UTC)Reply[reply]

  • Yes, it is reasonable. Maybe also port (P1641) can be used for protocol number of IP protocol: . DrSauron (talk) 18:34, 20 June 2015 (UTC)Reply[reply]
    I've seen firewalls that do it that way: If the protocol "Other" is selected on the firewall, then the "port" number is really a protocol number from list of IP protocol numbers (Q1342640). I've always wondered if that was wise generally, or just a convenience for firewalls that would never do anything more complex. If we have protocol numbers, we should probably have a separate property. At least one protocol outside of IP has something like both at once. IPX (Q855158), the basic protocol from IPX/SPX (Q39532), has both: a one-byte "type", which is a bit like an IP protocol number; and a "socket number" that is a bit like a port number, but exists in all types because it's built into the overall source and destination addresses themselves, not encapsulated in another protocol. --Closeapple (talk) 22:24, 20 June 2015 (UTC)Reply[reply]

Would be nice if it supported ranges edit

IRC has some range assignments for ports: IANA port assignments

Would be nice if there was some way to capture it in Iwan.Aucamp (talk) 12:24, 3 February 2020 (UTC)Reply[reply]

Port role edit

Currently this property only allows specifying the protocol, using of (P642), but for multi-ports protocols, like File Transfer Protocol (Q42283) or XMPP (Q188951), we should be able to specify the role of the port in the protocol. Currently File Transfer Protocol (Q42283) uses has use (P366) and XMPP (Q188951) uses subject has role (P2868) for this use case. Not sure what is the best (object has role (P3831) seems better?), but I think we should elect one and change the constraints accordingly. Ltrlg[as Ltrtst] (talk) 11:35, 10 February 2020 (UTC)Reply[reply]

Planned deprecation of of (P642) edit

This property currently uses of (P642) as a mandatory qualifier to specify the protocol to which the port number applies. of (P642) is set to be deprecated, and replacement properties must be determined for all its use cases. I propose using the existing protocol (P2700) for this purpose. Is that reasonable? Swpb (talk) 19:24, 1 December 2022 (UTC)Reply[reply]

No response; implementing. Swpb (talk) 20:07, 23 February 2023 (UTC)Reply[reply]
@Swpb I've noticed that of (P642) is still being used for most-if-not-all uses of port (P1641), despite this being depricated since Feb 2023 in favour of the protocol (P2700) qualifier. Should a script be created to upgrade uses of the old format, or should I just start fixing them manually? I just wanted to check before editing a load of protocol items. BEANS X2 (talk) 16:08, 26 April 2023 (UTC)Reply[reply]
By all means, write a script! And if you're willing, we could use scripts for lots of other deprecated use cases of P642 as well! Swpb (talk) 16:56, 26 April 2023 (UTC)Reply[reply]
Thanks for the reply! I've added port (P1641) to the list of allowed qualifiers, since it somehow wasn't there already. Creating a script to update the 378 uses of the port qualifier shouldn't be too difficult. (Famous last words!) If I understand correctly, I'll need to go through Wikidata:Requests for permissions/Bot before I start. BEANS X2 (talk) 18:28, 26 April 2023 (UTC)Reply[reply]
Done! All outdated uses have now been updated by User:BEANS Bot. I've also removed "of" from the allowed qualifiers constraint since there isn't a valid use for it anymore. BEANS X2 (talk) 18:51, 28 May 2023 (UTC)Reply[reply]
Return to "P1641" page.