Re: Fw: Purpose of Port 0. (About Bug 1068)

[Danny Niu]

Sorry, I wasn't quite clear what you mean by "What I suggest in Bug 1068 is 
intended to be along those lines", I might be able to use a bit of explanation. 
As in: what do you suggest we do and not do to the current texts of the 
standard, and why? 

I actually thought that port 0 was reserved *because of* its usage in BSD 
sockets apis. That why I sent the message to IETF asking the "purpose of port 
0". Unfortunately, the original assignee of the port, dear old Jon Postel had 
passed away. They replied me however, with the currently documented uses (and 
non-uses) of port 0. 

For the time being, I think application programmers will have to rely on system 
manpages and other secondary sources. 


From: shwares...@aol.com 
Sent: Wednesday, February 22, 2017 03:07
To: danny...@hotmail.com; austin-group-l@opengroup.org
Subject: Re: Fw: Purpose of Port 0. (About Bug 1068)

Afaik, sockets as a concept are a later encapsulation of the DARPA
protocols of the '60s which IETF inherited stewardship to, timeline wise.
I'd expect "Berkeley Sockets API" to be an informative reference of
XNS 5.2 or earlier, the document Issue 6 appropriated 
from, as noted in Change History. I agree with MarkA, it's not IETFs  job
to overload the definition of Port 0 to match what can be considered
erroneous behavior introduced by a few platforms, however significant
historically. The definition is spread over a few RFCs, but there is  one.

They can assign a usage all platforms could potentially
support to a reserved or unreserved port that has no definition assigned
or extend the scope of an existing definition to encompass more
unassigned ports. What I suggest in Bug 1068 is intended to be
along those lines. If BSD had defined debugging-specific protocol variants
of TCP and UDP, then how they might overload port 0 is limited to those
variants, and that isn't IETFs job to endorse/disallow either; it's
consistent
with how port 0 is already defined and platforms can elect not to support
that protocol without breaking other protocols.

As a POSIX conformance matter I'd consider that an expected extension,
but still an extension that should be tied to NDEBUG or other feature test
macro for enabling. If the test suite doesn't have the cases necessary to
detect it as an extension I'd hesitate to say Open Group should decertify
existing platforms or apps retroactively. As functionality accessed mostly
in debugging scenarios before a new protocol is registered and gets
official
port assignments it may be something insignificant to release package
usage. It would be more they don't get (re-)certified for a new standard
issue
without correcting it now that it's been identified as a possible failure
point,
if code expecting this behavior is left in a package tendered for
certification.

In a message dated 2/20/2017 7:16:13 A.M. Eastern Standard  Time,
danny...@hotmail.com writes:
I went to the IETF people, they feel they  shouldn't do it either. But they
mentioned it's a BSD sockets convention.

Does BSD sockets have referencial value in POSIX sockets? If so, can we
get an Application Usage section for it?

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-21 14:07 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
== 

-- 
 (0003565) shware_systems (reporter) - 2017-02-21 14:07
 http://austingroupbugs.net/view.php?id=1119#c3565 
-- 
Also, note the ellipsis on the file operand. If it was required to return
non-zero if any operand was not present, a script wouldn't know which
operand the return applied to anyways. This proposal could be an extension
behavior for the limiting case of only one file operand, but 'test -e file'
already provides the same info unambiguously. The Exit Status section could
be more descriptive that >0 returns relate to system conditions like
utility not found/not executable or out of memory/file handles, and not
about a particular operand.

As an aid to parsing, numbering the file types expected to be reported and
including this in the output for each file, using "%s:%2d %s" as first part
of format strings, would be more the way I'd expect an extension to be
implemented. This can be added to the current outputs anyways without
affecting conformance, but then the number assignments would be more prone
to vary among implementations. This would also distinguish the 'does not
exist' case from the 'cannot read/write only' case. A new switch, e.g.
-n[umber code], could control whether this format is used instead of the
current one for backwards compatibility purposes. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
2017-02-21 01:55 Vincent LefevreNote Added: 0003563  
2017-02-21 12:06 joerg  Note Added: 0003564  
2017-02-21 14:07 shware_systems Note Added: 0003565  
==

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-21 12:06 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
== 

-- 
 (0003564) joerg (reporter) - 2017-02-21 12:06
 http://austingroupbugs.net/view.php?id=1119#c3564 
-- 
Besides the fact that such a change could break existing scripts, file's
task is to return information about the path name and:

LC_ALL=C file /tmp/missing 
/tmp/missing:  cannot open: No such file or directory

may be seen as "information" about the path in question. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
2017-02-21 01:55 Vincent LefevreNote Added: 0003563  
2017-02-21 12:06 joerg  Note Added: 0003564  
==