On Sat, Nov 30, 2024 at 03:18:45PM -0800, Erik Kline via Datatracker wrote:
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
> CC @ekline
>
> ## Comments
>
> * "typedef protocol-number {
> If IPv6 extension headers are present, then the
> protocol number type represents the upper layer protocol
> number, i.e., the number of the last 'next header' field
> of the IPv6 extension headers."
>
> Surely since this can represent all values of the Next Header field this
> _could_ indicate the value of an IPv6 Extension Header?
>
> It seems to me that we should just say this is the value of the
> protocol/next header field wherever this numberspace is indicated, and
> that in some contexts extension headers might be skipped over and the
> ultimate next header value is what is meant in this field.
>
> This should be called out on a case-by-case basis, though, I would expect
> (i.e. wherever this type is used).
These are possible alternate semantics making the type more flexible
to use but also requiring that every usage spells out what is actually
meant.
> * ipv[46]-address-no-zone
>
> Why are these patterns so much more permissive than the non-zone parts
> of the address patterns? Why not just copy the address pattern text and
> leave off the %<zone> pattern chunk?
Because these typedefs are _derived_ from the ipv4-address and
ipv6-address and hence both pattern apply.
> * email-address
>
> This pattern seems overly permissive. It appears to permit the RFC 5322
> S3.2.3 "specials" that are not part of "dot-atom".
>
> I'm no SMTP expert, but it seems like at least excluding the @ special
> might help? E.g.
>
> [^@]+@[^@]+
>
> or something.
There as a version where we tried to capture many of the email address
format but that turned out to lead to a very long pattern that still
was not capturing everything correctly and failed badly on
internationalized email addresses. So we went back to a rather
simplistic pattern since implementations will need specific code to
properly validate (international) email addresses.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
