Attention NETMOD WG,
This email begins a two-week poll confirming the WG consensus for fourvopen
issues DISCUSS items related to rfc6991-bis. If no objections are received by
May 22, the positions will be confirmed.
Background: During NETMOD 122, Mahesh presented open DISCUSS issues on the
rfc6991-bis document. Unfortunately, the discussion was incomplete. so this
email presents the open DISCUSS issues again, with a default position for each.
There are four open DISCUSS issues. One from Erik and three from Orie.
Erik's DISCUSS (regarding the "mac-address" typedef)
Orie's DISCUSS #1( Time)
Orie's DISCUSS #2 (URI Normalization)
Orie's DISCUSS #3 (Did you mean A-Labels?)
Each of these DISCUSS issues are presented below.
1) Erik's DISCUSS (regarding the "mac-address" typedef)
Issues:
Regex used in ‘typedef mac-address’ is incorrect
- it's an overloaded term
- mac-address can vary from 16 to 64 bits (802.15.4),
not just 48 bits
Possible Solutions:
a) Fix the regex to accommodate 16 and 64-bit
- But there is a ‘phys-address’
b) Clarify that ‘mac-address’ as defined applies to IEEE 802.3
and 802.11
- Currently, we reference IEEE 802 (without any
qualifiers)
The poll conducted regarding option (b)
Can You Accept If We Just Clarify The Description Statement
For Mac-Address?
The results were:
Good participation with majority Yes responses
Any objections?
2) Orie's DISCUSS #1( Time)
I suggest something like:
RFC6021 defined the canonical format for date-and-time in a way that is not
directly compatible with dateTime XML Schema type, or the guidance provided in
RFC 9557 which updated RFC 3339.
If the time in UTC is known, but the offset to local time is unknown, this
SHOULD be represented with an offset of "Z", and MAY be represented using
"-00:00" for backwards compatibility.
Note that "Z" and "-00:00" are semantically different from an offset of +00:00,
which implies that UTC is the preferred reference point for the specified time.
Any objections?
3) Orie's DISCUSS #2 (regarding URI Normalization)
There are two issues.
Issue #1:
The URI Normalization section says:
All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits within a percent-encoded triplet, which are
normalized to uppercase as described in Section 6.2.2.1
of RFC 3986.
Orie asks:
What is “unnecessary percent encoding”?
The poll conducted:
Can You Accept Removing The Unnecessary Encoding Text?
Note: should say "Percent Encoding" (not just
"Encoding")
The results were:
Reasonable participation. Approximate ratio of responses 2:1:5
NA:No:Yes.
- so mostly "yes"
Any objections?
Issue #2:
Orie writes:
The URI Normalization section also says:
The purpose of this normalization is to help provide
unique URIs. Note that this normalization is not
sufficient to provide uniqueness. Two URIs that are
textually distinct after this normalization may still
be
equivalent.
Orie asks:
Also what is the value of producing unique URIs,
if not for comparison / equivalence checks?
Current position: no update to text.
Any objections?
4) Orie's DISCUSS #3 (Did you mean A-Labels?)
Orie quotes text from the document:
```
The domain part may use both A-labels and U-labels
(see RFC 5890). The canonical format of the domain part
uses lowercase characters and U-labels (RFC 5890) where
applicable.";
```
Seems strange to suggest U-Labels in a canonical format.
Also, is there a relevant length restriction here?
https://datatracker.ietf.org/doc/html/rfc5890#section-4.2
Consider just lifting the text for this section directly from:
https://datatracker.ietf.org/doc/html/rfc6531#section-3.2
```
When doing lookups, the SMTPUTF8-aware SMTP client or
server MUST either use a Unicode-aware DNS library, or transform the
internationalized domain name to A-label form (i.e., a fully-
qualified domain name that contains one or more A-labels but no
U-labels)
```
Current position: no update to text.
Any objections?
Kent as chair (and Mahesh as AD)
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
