Hi, That interpretation is correct. I recall some discussion of this from IETF 122, which I agreed with. When you have a new version posted, please ping me and I will see if I can clear my discuss.
Regards, OS On Tue, Jun 3, 2025 at 7:17 PM Mahesh Jethanandani <[email protected]> wrote: > Correcting Orie’s email address. > > On Jun 3, 2025, at 1:24 PM, Mahesh Jethanandani <[email protected]> > wrote: > > [Speaking as a contributor and adding Orie in case I might be misspeaking] > > On Jun 3, 2025, at 7:16 AM, Kent Watsen <[email protected]> wrote: > > NETMOD, > > We're past the confirmation period for this poll. > > One response came in - thanks Rob! The good news is that his response > didn't object to most (all but one) DISCUSS positions, which I think means > (per the message below) that the others positions are now confirmed. This > leaves open only the one DISCUSS item that Rob objected to the position for. > > > The question Orie asked was “What is unnecessary percent encoding”? I > think an explanation, and some additional text in the draft, similar to > what Rob gives (and I reproduce here) might go a long way to satisfy Orie's > DISCUSS. > > My understanding of URIs is that some characters MUST be percent encoded, > but also that some other characters that don’t need to be percent encoded > may be percent encoded. E.g., “Reserved characters that have no reserved > purpose in a particular context may also be percent-encoded but are not > semantically different from those that are not.” From > https://en.wikipedia.org/wiki/Percent-encoding > > Hence, I interpret this text is that for normalization purposes, if the > character can be represented without using percent encoding then it MUST > use the non percent encoded form. As such, I think that the exist text, or > something like it, it probably useful and should be retained. > > > Thanks > > > Can folks please chime in on this thread so we can finally put this > document behind us? > > Thank you! > > Kent > > > On May 8, 2025, at 6:17 PM, Kent Watsen <[email protected]> wrote: > > 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. > > > 1. Erik's DISCUSS (regarding the "mac-address" typedef) > 2. Orie's DISCUSS #1( Time) > 3. Orie's DISCUSS #2 (URI Normalization) > 4. 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] > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > Mahesh Jethanandani > [email protected] > > > Mahesh Jethanandani > [email protected] > > > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
