Correcting Orie’s email address. > On Jun 3, 2025, at 1:24 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > [Speaking as a contributor and adding Orie in case I might be misspeaking] > >> On Jun 3, 2025, at 7:16 AM, Kent Watsen <kent+i...@watsen.net >> <mailto:kent+i...@watsen.net>> 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 > <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 <kent+i...@watsen.net >>> <mailto:kent+i...@watsen.net>> 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. >>> >>> 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 >>> <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 >>> <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 -- netmod@ietf.org <mailto:netmod@ietf.org> >>> To unsubscribe send an email to netmod-le...@ietf.org >>> <mailto:netmod-le...@ietf.org> >> >> _______________________________________________ >> netmod mailing list -- netmod@ietf.org <mailto:netmod@ietf.org> >> To unsubscribe send an email to netmod-le...@ietf.org >> <mailto:netmod-le...@ietf.org> > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
