[port-srv-reg] Fixes for spelling, grammar, punctuation, etc.

[Stuart Cheshire <[e-mail]>]

I just checked in a few minor changes to fix spelling, grammar, punctuation, awkward sentence structure, etc.

I think all these changes should be self-explanatory and don't alter the meaning of what the document says, but if anything is not clear feel free to ask for more explanation.

Stuart Cheshire <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

Index: draft-ietf-tsvwg-iana-ports.xml
===================================================================
--- draft-ietf-tsvwg-iana-ports.xml	(revision 79)
+++ draft-ietf-tsvwg-iana-ports.xml	(working copy)
@@ -210,8 +210,8 @@
       assignment of service names and port numbers, this document also
       specifies post-assignment procedures that until now have been handled in
       an ad hoc manner. These include procedures to de-register a port number
-      that is no longer in use, to re-use a port number allocated for one
-      application that is no longer in use for another application, and the
+      that is no longer in use, to take a port number allocated for one
+      application that is no longer in use and reuse it for another application, and the
       procedure by which IANA can unilaterally revoke a prior port number
       assignment. <xref target="iana-procedures"></xref> discusses the
       specifics of these procedures and processes that requesters and IANA
@@ -234,9 +234,9 @@
       allocation procedures for DCCP <xref target="RFC4340"></xref> and SCTP
       <xref target="RFC4960"></xref>.</t>
 
-      <t>The Lightweight User Datagram Protocol (UDP-Lite) <xref
-      target="RFC5237"></xref> shares the port space with UDP. The UDP-Lite
-      specification says: "UDP-Lite uses the same set of port number values
+      <t>The Lightweight User Datagram Protocol (UDP-Lite) shares the port space
+      with UDP. The UDP-Lite specification <xref target="RFC5237"></xref> says:
+      "UDP-Lite uses the same set of port number values
       assigned by the IANA for use by UDP". Thus the update of UDP procedures
       result in an update also of the UDP-Lite procedures.</t>
 
@@ -275,15 +275,17 @@
 
       <t>Similarly, the procedures surrounding service names have been
       historically unclear. Service names were originally created as mnemonic
-      identifiers for port numbers without a well-defined syntax, beyond the
+      identifiers for port numbers without a well-defined syntax, apart from the
       14-character limit mentioned on the IANA website <xref
       target="SYSFORM"></xref> <xref target="USRFORM"></xref>. Even that
       length limit has not been consistently applied, and some assigned
       service names are 15 characters long. When service identification via
-      DNS SRV Resource Records (RRs) was introduced, the requirement by IANA
-      to only assign service names and port numbers in combination, led to the
-      creation of an ad hoc service name registry outside of the control of
-      IANA <xref target="SRVREG"></xref>.</t>
+      DNS SRV Resource Records (RRs) was introduced <xref target="RFC2782"></xref>,
+      it became useful to start requesting service names alone, and because IANA
+      had no procedure established for allocating a service name without an
+      associated fixed port number this lead to the creation, outside of the
+      control of IANA, of an informal temporary service name registry which now
+      contains roughly 500 service names <xref target="SRVREG"></xref>.</t>
 
       <!--
       This text duplicates what's said elsewhere in the document.
@@ -343,7 +345,7 @@
       Internet communication. Ports serve two purposes: first, they provide a
       demultiplexing identifier to differentiate transport sessions between
       the same pair of endpoints, and second, they may also identify the
-      application protocol and associated service to which processes bind.
+      application protocol and associated service to which processes connect.
       Newer transport protocols, such as the Stream Control Transmission
       Protocol (SCTP) <xref target="RFC4960"></xref> and the Datagram
       Congestion Control Protocol (DCCP) <xref target="RFC4342"></xref> have
@@ -412,7 +414,7 @@
         </list></t>
 -->
 
-      <t>Applications may use numeric port numbers directly, look up port
+      <t>Applications may use numeric ports directly, look up port
       numbers based on service names via system calls such as getservbyname()
       on UNIX, look up port numbers by performing queries for DNS SRV records
       <xref target="RFC2782"></xref><xref
@@ -460,7 +462,7 @@
       about who is the Registrant for a particular entry.</t>
 
       <t>There may be more than one service name associated with a particular
-      transport protocol and port. There are three ways that such service name
+      transport protocol and port. There are three ways that such port number
       overloading can occur: <list style="symbols">
           <t>Overloading occurs when one service is an extension of another
           service, and an in-band mechanism exists for determining if the
@@ -469,14 +471,13 @@
           target="RFC5766"></xref> is an extension to the STUN <xref
           target="RFC5389"></xref> service. TURN-enabled clients wishing to
           locate TURN servers could attempt to discover "stun" services and
-          then check in-band if the server supports TURN, but this would be
+          then check in-band if the server also supports TURN, but this would be
           inefficient. Enabling them to directly query for "turn" servers by
           name is a better approach. (Note that TURN servers in this case
           should also be locatable via a "stun" discovery, because every TURN
           server is also a STUN server.)</t>
 
-          <t>By historical accident the service name "http" corresponds to
-          the same port number as 
+          <t>By historical accident the service name "http" has two synonyms
           "www" and "www-http". When used in SRV records <xref
           target="RFC2782"></xref>, and similar service discovery mechanisms
           only the service name "http" should be used, not these additional
@@ -487,8 +488,8 @@
           achieves nothing that it not already achieved by using the service
           name "http" exclusively.</t>
 
-          <t>As indicated in this document, in 
-          <xref target="consistency"></xref>, to enable	
+          <t>As indicated in this document in 
+          <xref target="consistency"></xref>, overloading occurs to enable	
           legacy names to be replaced with names consistent with the	
           syntax this document prescribes. In this case, only the	
           new name should be used in SRV records, both to avoid	
@@ -529,8 +530,8 @@
           </list></t>
 
         <t>The reason for requiring at least one letter is to avoid service
-        names like "23" (could be confused with a numeric port number) or
-        "6000-6063" (could be confused with a numeric port number range).
+        names like "23" (could be confused with a numeric port) or
+        "6000-6063" (could be confused with a numeric port range).
         Although service names may contain both upper-case and lower-case
         letters, case is ignored for comparison purposes, so both "http" and
         "HTTP" denote the same service.</t>
@@ -584,7 +585,8 @@
         what this means.</t>
 
         <t>This document clarifies that the Service Label MUST be a service
-        name as defined herein. The service name SHOULD be registered with
+        name as defined herein with an underscore prepended.
+        The service name SHOULD be registered with
         IANA and recorded in the Service Name and Transport Protocol Port
         Number Registry <xref target="PORTREG"></xref>.</t>
 
@@ -738,7 +740,7 @@
 
       <section anchor="upprinc" title="Updated Principles">
         <t>This section summarizes the basic principles by which IANA handles
-        the Service Name and Transport Protocol Port Number Registry, and
+        the Service Name and Transport Protocol Port Number Registry and
         attempts to conserve the port number space. This description is
         intended to inform applicants requesting service names and port
         numbers. IANA are not required to be bound by these principles 
@@ -765,8 +767,9 @@
         <t>Conservation of the port number space is required because this
         space is a limited resource, so applications are expected to
         participate in the traffic demultiplexing process where feasible. The
-        port numbers are expected to encode as little information as possible
-        that will still enable an application to perform further
+        port numbers are expected to encode as little information as possible that will
+<?rfc needLines="17" ?>
+        still enable an application to perform further
         demultiplexing by itself. In particular:</t>
 
         <t><list style="symbols">
@@ -774,8 +777,8 @@
             application</t>
 
             <t>IANA will allocate only one assigned port number for all
-            versions of a service (e.g., running the service with or without a
-            security mechanism, or for updated variants of a service)</t>
+            variants of a service (e.g., running the service with or without a
+            security mechanism, or for updated versions of a service)</t>
 
             <t>IANA will allocate only one assigned port number for all
             different types of device using or participating in the same
@@ -820,7 +823,7 @@
         drawing conclusions about the service that generated a given flow
         based on observed port numbers is not always reliable. <!-- (again, as discussed in detail in
         <xref target="I-D.touch-tsvwg-port-guidelines"/>).--> Further,
-        previous separation of protocol variants based on security
+        the previous practice of separating protocol variants based on security
         capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
         not recommended for new protocols, because all new protocols should be
         security-capable and capable of negotiating the use of security
@@ -870,7 +873,7 @@
       <t>This section describes the process for handling requests associated
       with IANA's management of the Service Name and Transport Protocol Port
       Number Registry. Such requests include initial registration,
-      de-registration, re-use, changes to the service name, and updates to the
+      de-registration, reuse, changes to the service name, and updates to the
       contact information or description associated with an assignment.
       Revocation is as additional process, initiated by IANA.</t>
 
@@ -880,7 +883,8 @@
         numbers to applicants. All such registrations are made from service
         names or port numbers that are Unassigned or Reserved at the time of
         the allocation. Unassigned names and numbers are allocated according
-        to the rules described in <xref target="variances"></xref> below. Reserved
+        to the rules described in <xref target="variances"></xref> below.
+        Except as described below, Reserved
         numbers and names are assigned only by Standards Action or IESG Approval,
         and MUST accompanied by a statement explaining the reason a Reserved
         number or name is appropriate for this action.</t>
@@ -893,7 +897,7 @@
         for a port number MAY register these Reserved port numbers for other
         transport protocols when needed.</t>
 
-        <t><vspace blankLines="14" />A service name or port number
+        <?rfc needLines="14" ?><t>A service name or port number
         registration request contains the following information. The service
         name is the unique identifier of a given service:</t>
 
@@ -933,7 +937,7 @@
             <t>Contact: Name and email address of the Contact person for the
             registration. This is REQUIRED. The Contact person is the
             responsible person for the Internet community to send questions
-            to. This person would also be authorized to submit changes on
+            to. This person is also authorized to submit changes on
             behalf of the Registrant; in cases of conflict between the
             Registrant and the Contact, the Registrant decisions take precedence. 
             Additional address information MAY be
@@ -966,9 +970,8 @@
             RFC.</t>
 
             <t>Port Number: If assignment of a port number is desired, 
-            either the currently Unassigned or Reserved port number the 
-            requester suggests for allocation, or indication of which 
-            port range, user or system, that the requester requires, 
+            either the port number the requester suggests for allocation
+            or indication of port range (user or system)
             MUST be provided. If only a service name is to be assigned, 
             this field is left empty. If a specific port number is 
             requested, IANA is encouraged to allocate the requested 
@@ -998,13 +1001,15 @@
           </list></t>
 
         <t>If the registration request is for the addition of a new transport
-        protocol to an already assigned service name, IANA needs to confirm
+        protocol to an already-assigned service name and the requester is not the
+        Registrant or Contact for the already-assigned service name, IANA needs to confirm
         with the Registrant for the existing assignment whether
         this addition is appropriate.</t>
         
-        <t>If the registration request is for a service name overloading a 
-        port number (see Section 5), IANA needs to confirm with the 
-        Registrant for the existing service name whether the registration of
+        <t>If the registration request is for a new service name sharing the
+        same port as an already-assigned service name (see port number
+        overloading in <xref target="srvname"></xref>), IANA needs to confirm with the
+        Registrant for the existing service name and other appropriate experts whether
         the overloading is appropriate.</t>
 
         <t>When IANA receives a registration request - containing the 
@@ -1023,8 +1028,9 @@
             and port number registry: <list style="symbols">
                 <t>Ports in the Dynamic Ports range (49152-65535) have been
                 specifically set aside for local and dynamic use and cannot be
-                assigned through IANA. Application software may simply use them
-                for communication without any sort of registration. On the other
+                assigned through IANA. Application software may simply use
+                any dynamic port that is available on the local host,
+                without any sort of registration. On the other
                 hand, application software MUST NOT assume that a specific port
                 number in the Dynamic Ports range will always be available for
                 communication at all times, and a port number in that range hence
@@ -1053,9 +1059,8 @@
                 range, and will only be granted under the "IETF Review" or "IESG
                 Approval" allocation procedures <xref target="RFC5226"></xref>. A
                 request for a System Port number MUST document *both* why using a
-                port number from the User Ports is unsuitable *and* why using a
-                port number from the Dynamic Ports ranges is unsuitable for that
-                application.</t>
+                port number from the Dynamic Ports range is unsuitable *and* why using a
+                port number from the User Ports range is unsuitable for that application.</t>
               </list></t>
         </section>
 
@@ -1089,13 +1094,13 @@
         happens to indicate its historic usage.</t>
       </section>
 
-      <section anchor="reuse" title="Service Name and Port Number Re-Use">
+      <section anchor="reuse" title="Service Name and Port Number Reuse">
         <t>If the Registrant of a granted port number assignment
-        no longer have a need for the assigned number, but would like to
-        re-use it for a different application, they can submit a request to
+        no longer has a need for the assigned number, but would like to
+        reuse it for a different application, they can submit a request to
         IANA to do so.</t>
 
-        <t>Logically, port number re-use is to be thought of as a
+        <t>Logically, port number reuse is to be thought of as a
         de-registration (<xref target="deregistration"></xref>) followed by an
         immediate re-registration (<xref target="registration"></xref>) of the
         same port number for a new application. Consequently, the information
@@ -1106,8 +1111,8 @@
         <t>Because there is much less danger of exhausting the service name
         space compared to the port number space, it is RECOMMENDED that the
         original service name associated with the prior use of the port number
-        remains assigned, and a new service be created and associated with the
-        port number. This is again consistent with viewing a re-use request as
+        remains assigned, and a new service name be created and associated with the
+        port number. This is again consistent with viewing a reuse request as
         a de-registration followed by an immediate re-registration. Re-using
         an assigned service name for a different application is NOT
         RECOMMENDED.</t>
@@ -1172,14 +1177,14 @@
         to the Description and Contact information are coordinated by 
         IANA in an informal manner, and may be initiated by either the 
         registrant or by IANA, e.g., by the latter requesting an update 
-        to current contact information. (Note that Registrant cannot be 
+        to current contact information. (Note that the Registrant cannot be 
         changed; see <xref target="transfer"></xref>
         above.)</t>
       </section>
       
       <section title="Disagreements">
       <t>In the case of disagreements around any request there is the 
-      possibility of appeal following the normal appelas process for 
+      possibility of appeal following the normal appeals process for 
       IANA registrations as defined by Section 7 of <xref target="RFC5226">
       "Guidelines for Writing an IANA Considerations Section in RFCs"</xref>.
       </t>
@@ -1274,7 +1279,7 @@
         historic, not usable for use with many common service discovery
         mechanisms.</t>
 
-        <t><vspace blankLines="42" />Names containing illegal characters to be
+        <?rfc needLines="34" ?><t>Names containing illegal characters to be
         replaced by hyphens:</t>
 
         <texttable>
@@ -1506,33 +1511,27 @@
 
           <ttcol></ttcol>
 
-          <c>Registrant</c>
-
-          <c>IETF &lt;[e-mail]&gt;</c>
-
-          <c>Contact</c>
-
-          <c>IESG &lt;[e-mail]&gt;</c>
-
           <c>Service Name</c>
-
           <c>exp1</c>
 
-          <c>Port Number</c>
-
-          <c>1021</c>
-
           <c>Transport Protocol</c>
-
           <c>DCCP, SCTP, TCP, UDP</c>
 
-          <c>Description</c>
+          <c>Registrant</c>
+          <c>IETF &lt;[e-mail]&gt;</c>
 
+          <c>Contact</c>
+          <c>IESG &lt;[e-mail]&gt;</c>
+
+          <c>Description</c>
           <c>RFC3692-style Experiment 1</c>
 
           <c>Reference</c>
+          <c>[RFC 4727] [RFCyyyy]</c>
 
-          <c>[RFCyyyy],RFC 4727]</c>
+          <c>Port Number</c>
+          <c>1021</c>
+
         </texttable>
 
         <texttable>
@@ -1540,33 +1539,26 @@
 
           <ttcol></ttcol>
 
-          <c>Registrant</c>
-
-          <c>IETF &lt;[e-mail]&gt;</c>
-
-          <c>Contact</c>
-
-          <c>IESG &lt;[e-mail]&gt;</c>
-
           <c>Service Name</c>
-
           <c>exp2</c>
 
-          <c>Port Number</c>
-
-          <c>1022</c>
-
           <c>Transport Protocol</c>
-
           <c>DCCP, SCTP, TCP, UDP</c>
 
-          <c>Description</c>
+          <c>Registrant</c>
+          <c>IETF &lt;[e-mail]&gt;</c>
 
+          <c>Contact</c>
+          <c>IESG &lt;[e-mail]&gt;</c>
+
+          <c>Description</c>
           <c>RFC3692-style Experiment 2</c>
 
           <c>Reference</c>
+          <c>[RFC4727] [RFCyyyy]</c>
 
-          <c>[RFCyyyy], [RFC4727]</c>
+          <c>Port Number</c>
+          <c>1022</c>
         </texttable>
 
         <t>[RFC Editor Note: Please change "yyyy" to the RFC number allocated
@@ -1587,7 +1579,7 @@
           <t><list style="symbols">
               <t>IANA MAY assign new Service Codes without seeking Expert
               Review using their discretion, but SHOULD seek expert review if
-              a request seeks more than five Service Codes.</t>
+              a request asks for more than five Service Codes.</t>
 
               <t>IANA should feel free to contact the DCCP Expert Reviewer
               with questions on any registry, regardless of the registry
@@ -1622,7 +1614,7 @@
               registry.</t>
 
               <t>A request for additional Service Codes to be associated with
-              an already allocated Port Number requires Expert Review. These
+              an already-allocated Port Number requires Expert Review. These
               requests will normally be accepted when they originate from the
               contact associated with the port registration. In other cases,
               these applications will be expected to use an unallocated port,
@@ -1645,7 +1637,7 @@
 
     <section anchor="ack" title="Acknowledgments">
       <t>The text in <xref target="dccp"></xref> is based on a suggestion
-      originally proposed as a part of the DCCP Service Codes document<xref
+      originally proposed as a part of the DCCP Service Codes document <xref
       target="RFC5595"></xref> by Gorry Fairhurst.</t>
 
       <t>Lars Eggert is partly funded by the Trilogy Project <xref