Re: [IPv6] [art] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

[Brian E Carpenter <[e-mail]>]

On 27-Mar-23 07:55, Rob Sayre wrote:
> Hi,
> 
> I think the introduction should be changed a little bit. The document hurts its own credibility right at the start:
> 
> "The Uniform Resource Identifier (URI) syntax specification [RFC3986]
> defined how a literal IPv6 address can be represented in the "host"
> part of a URI.  Two months later, the IPv6 Scoped Address
> Architecture specification [RFC4007]..."
> 
> This is a stretch. RFC 3986 (or STD 66) was not exactly a fast-moving effort, for good reason. This text makes it sound like there was an unforeseeable problem due to concurrent work, but I don't think that is true.

Well, if that text had any snarky intention, it was to suggest that RFC4007 made a major mistake by picking "%" as the delimiter. We clearly didn't do a good enough job of cross-area review at that time. I didn't realise the problem myself for years, so I certainly share the blame. We can rephrase it, I guess.

> 
> I don't understand many of the rationales in Appendix A. For example, the one about the underscore just isn't true. Try something like this:
> <a href="https://ietf.org <https://ietf.org>">an_underscore</a>

It depends on the browser. With an actual example:

<a href="http://[fe80::abcd_eth0]">http://[fe80::abcd_eth0]</a>

the underscore is nicely visible on Firefox, but much less so on Chrome and Edge; with the latter two a person with poor vision could miss it, IMHO. When I revive Internet Explorer, the underscore is completely obscured. (I took the liberty of attaching a small screenshot with both my and your examples.)

I agree that this argument is largely outdated, but it's a detail. If we were able to change the delimiter in RFC4007, we'd probably choose "-" anyway, although somebody suggested "~" and that would work too.

> 
> Additionally, copy/paste of URLs is usually incredibly complicated in all situations (not a "simple copy/paste"). So, I'm not sure I buy a lot of the other bullet points.

Look at the use cases. Technicians cut-and-paste URLs all the time, and they will increasingly cut-and-paste IPv6 addresses for other reasons. It's just that the difference between simply pasting fe80::2e3a:fdff:fea5:dce7%7 and constructing fe80::2e3a:fdff:fea5:dce7-7 takes time and is error-prone.

I certainly can't imagine that a help desk script for this process would be straightforward.

If the parser experts were saying 'we cannot parse it with the "%" but we could parse it with the "-"', that would change the discussion, but we've never heard that.
  
> But what I think I'm reading between the lines here is that someone has already shipped this. If that's the case, well what can you do? :)

Well, Firefox shipped it many years ago, but later withdrew it. Microsoft have shipped code that *generates* URLs like http://[fe80::823b:f9ff:fe7b:d9dc%10]:80/WebServices/Device, even though their own browser doesn't handle it. A few techie users have been complaining for years, and the argument is that we're going to *need* it, as IPv6-only deployments with multiple subnets grow in number.

    Brian

> 
> thanks,
> Rob
> 
> 
> On Sun, Mar 26, 2023 at 8:58 AM Larry Masinter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     I asked for a brief explanation. The response explains, albeit not directly.
> 
>     I regret going down this path with RFC 2732: Format for Literal IPv6 Addresses in URL's (rfc-editor.org) <https://www.rfc-editor.org/rfc/rfc2732>
>     If I had do-overs (in another universe) I would have pushed harder
>     The Compatibility Dilemma (ietf.org) <https://www.ietf.org/proceedings/47/slides/idn-url-00mar/sld003.htm>
> 
>     On Sun, Mar 26, 2023 at 5:10 AM Michael Sweet <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         Another point: there are other URI schemes that benefit from this work, not the least of which are “ipp” and “ipps”, which are used by billions of printers and client devices worldwide. This is really an edge case for supporting access to devices when the preferred mechanism (mDNS hostnames) is not available.
> 
>         So I really don’t want and don’t support pushing for new URI schemes.
> 
>         ____________________
>         Michael Sweet
> 
>          > On Mar 26, 2023, at 2:34 AM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>          >
>          > It's simply irrelevant to the use cases, which are all well-established uses of http: and https:. Nobody has any need of a new scheme for these use cases.
>          >
>          > Also, the URI will still have to be parsed. I don't see how it changes anything, unless you imagine that browser implementers will write new parsers just for this.
>          >
>          > There's running code proof that by adding the appropriate case to an existing parser, the proposal just works. At this point I am baffled by this new suggestion.
>          >
>          > My question at the moment is a simple one: which of the points raised in the ART review are not answered in the latest posted draft?
>          >
>          > Regards
>          >   Brian Carpenter
>          >
>          >> On 26-Mar-23 18:10, Martin J. Dürst wrote:
>          >> Hello Brian, others,
>          >>> On 2023-03-26 13:54, Brian E Carpenter wrote:
>          >>> We seem to be in different universes here.
>          >> Good to know. Actually, Martin Thomson and me discussed the possibility
>          >> of (a) dedicated scheme(s) as an alternative just this morning. It might
>          >> be possible to avoid quite a bit of the issues that Martin brought up in
>          >> his review.
>          >> Regards,   Martin.
>          >>> Regards
>          >>>     Brian Carpenter
>          >>>
>          >>> On 26-Mar-23 17:21, Larry Masinter wrote:
>          >>>> i don't understand the use cases that wouldn't use httpv6 and httpsv6.
>          >>>> If you get a URL with a new scheme, you either know what to do with it
>          >>>> or you don't, but in the latter case you know that you don't know.
>          >>>> Unlike all of the plans to extend http and https to have a new syntax.
>          >>>>
>          >>>> On Sat, Mar 25, 2023 at 9:07 PM Brian E Carpenter
>          >>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>          >>>>
>          >>>>     Larry,
>          >>>>
>          >>>>     In a word, the use cases are HTTP and HTTPS use cases.
>          >>>>
>          >>>>     Regards
>          >>>>          Brian Carpenter
>          >>>>
>          >>>>     On 26-Mar-23 16:33, Larry Masinter wrote:
>          >>>>      > I haven't been following closely, but perhaps someone might
>          >>>> take a moment to explain why defining a new scheme isn't preferable to
>          >>>> changing the parsing rules for old schemes?
>          >>>>      >
>          >>>>      > On Sat, Mar 25, 2023 at 7:57 PM Martin Thomson
>          >>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
>          >>>>      >
>          >>>>      >     Despite sessions being busy, my extrasessionary schedule is
>          >>>> light.
>          >>>>      >
>          >>>>      >     Would 16:30 Tuesday work for people?  A side meeting room
>          >>>> is presently available at that time.
>          >>>>      >
>          >>>>      >     On Sun, Mar 26, 2023, at 11:36, Martin J. Dürst wrote:
>          >>>>      >      > I just happened to bump into Martin Thomson at the IETF
>          >>>> hackathon in
>          >>>>      >      > Yokohama. We discussed this draft, and thought we might
>          >>>> be able to
>          >>>>      >      > organize a little side meeting to discuss the issues and
>          >>>> hopefully also
>          >>>>      >      > make some progress. We know that Brian is remote, but we
>          >>>> will try to
>          >>>>      >      > have a setup where he can participate remotely.
>          >>>>      >      >
>          >>>>      >      > We welcome everybody from the IPv6 and URI side who is
>          >>>> interested;
>          >>>>      >      > that's the reason for cross-posting. Martin Thomson is
>          >>>> way more busy
>          >>>>      >      > than me, so I'm letting him (or anybody else) propose
>          >>>> some time slots.
>          >>>>      >      >
>          >>>>      >      > Regards,   Martin.
>          >>>>      >      >
>          >>>>      >      > On 2023-03-16 22:54, Francesca Palombini wrote:
>          >>>>      >      >> Martin: thank you very much for this review. I have
>          >>>> looked at the following responses as well, and I am not sure that
>          >>>> there was ever a conclusion to the mail thread, although I can see
>          >>>> that Brian did try to make modifications and clarifications in the
>          >>>> text as much as possible. Murray has balloted DISCUSS following your
>          >>>> review and subsequent discussion, and I support his DISCUSS in my
>          >>>> ballot (1). We will talk about it today. If you have any insight about
>          >>>> Murray’s question: Do any of the communities rejecting it have a
>          >>>> preferred alternative for achieving the stated goal? It would be helpful.
>          >>>>      >      >>
>          >>>>      >      >> Thanks,
>          >>>>      >      >> Francesca
>          >>>>      >      >>
>          >>>>      >      >>
>          >>>>      >      >>    1.
>          >>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>
>          >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>>
>          >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>
>          >>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/>>>
>          >>>>      >      >>
>          >>>>      >      >> From: last-call <[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>> on behalf of Martin Thomson via
>          >>>> Datatracker <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>
>          >>>>      >      >> Date: Friday, 16 September 2022 at 21:32
>          >>>>      >      >> To: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> <[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>
>          >>>>      >      >> Cc: [e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >>>> <[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>>, [e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>>, [e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>> <[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>>
>          >>>>      >      >> Subject: [Last-Call] Artart last call review of
>          >>>> draft-ietf-6man-rfc6874bis-02
>          >>>>      >      >> Reviewer: Martin Thomson
>          >>>>      >      >> Review result: Not Ready
>          >>>>      >      >>
>          >>>>      >      >> As a bit of a preface here, I've been aware of this
>          >>>> work for some time, but
>          >>>>      >      >> have refrained from offering opinion.  As liaison to
>          >>>> the W3C, I felt like my
>          >>>>      >      >> responsibility was to facilitate the conversation.
>          >>>> However, as Barry has asked
>          >>>>      >      >> me to do a review, I feel obligated to set that attempt
>          >>>> at neutrality aside.
>          >>>>      >      >>
>          >>>>      >      >> The biggest issue here is that this document is very
>          >>>> much unwanted by its
>          >>>>      >      >> target audience, as is its antecedent, RFC 6874.  I
>          >>>> share that concern.
>          >>>>      >      >>
>          >>>>      >      >> I have clear, strong indications from folks at three
>          >>>> major browsers
>          >>>>      >      >> (conveniently, I am at W3C TPAC this week and so was
>          >>>> able to talk with a few
>          >>>>      >      >> people directly on this topic; inconveniently, I've not
>          >>>> had a lot of time for
>          >>>>      >      >> this review) that this change to the URI specification
>          >>>> is not just something
>          >>>>      >      >> that they don't want to implement, but that it is not
>          >>>> good for the Web.  Public
>          >>>>      >      >> communications from them will be somewhat more polite
>          >>>> and circumspect, but it
>          >>>>      >      >> has been made clear to me that this change is not wanted.
>          >>>>      >      >>
>          >>>>      >      >> The IETF does occasionally publish specifications that
>          >>>> don't end up being
>          >>>>      >      >> implemented, but we usually look for signals that a
>          >>>> protocol might be
>          >>>>      >      >> implemented before even starting work.  Here, we have a
>          >>>> strong signal that a
>          >>>>      >      >> specification won't be implemented.  Mark Nottingham
>          >>>> asks the same question as
>          >>>>      >      >> well as point 1 in [1].  (I don't personally find his
>          >>>> second and third points
>          >>>>      >      >> to be especially problematic given adequate
>          >>>> consultation, but even there, there
>          >>>>      >      >> are a few concerns that I will outline below.)
>          >>>>      >      >>
>          >>>>      >      >> I do want to give due credit to the authors - Brian in
>          >>>> particular - for being
>          >>>>      >      >> very open and forthright in their consultation with the
>          >>>> affected constituency.
>          >>>>      >      >> They have been proactive and responsive in a nearly
>          >>>> exemplary fashion.
>          >>>>      >      >>
>          >>>>      >      >> Overall, I think that it would be better for the IETF
>          >>>> to declare RFC 6874 as
>          >>>>      >      >> Historic(al).  There might be some residual value in
>          >>>> RFC 4007 from a diagnostic
>          >>>>      >      >> perspective, but the use of zone identifiers in URIs
>          >>>> seems fundamentally
>          >>>>      >      >> incompatible with the goals of URIs.
>          >>>>      >      >>
>          >>>>      >      >> I do recognize that the Web and HTTP is not the only
>          >>>> protocol affected by this
>          >>>>      >      >> sort of change.  The goal is to change all URI types.
>          >>>> However, I believe that
>          >>>>      >      >> HTTP is pretty important here and I have a fair sense
>          >>>> that the sort of concerns
>          >>>>      >      >> I raise with respect to HTTP apply (or should apply) to
>          >>>> other schemes.
>          >>>>      >      >>
>          >>>>      >      >> ---
>          >>>>      >      >>
>          >>>>      >      >> There are a few technical concerns I have based on
>          >>>> reviewing the draft.  Some
>          >>>>      >      >> of these - on their own - are significant enough to
>          >>>> justify not publishing this
>          >>>>      >      >> document.
>          >>>>      >      >>
>          >>>>      >      >> Inclusion of purely local information in the
>          >>>> *universal* identity of a resource
>          >>>>      >      >> runs directly counter to the point of having a URI.
>          >>>> This creates some very
>          >>>>      >      >> difficult questions that the draft does not address.
>          >>>>      >      >>
>          >>>>      >      >> For instance (1), the Web security model depends on
>          >>>> having a clear definition
>          >>>>      >      >> for the origin of resources.  The definition of Origin
>          >>>> depends on the
>          >>>>      >      >> representation of the hostname and it relies heavily
>          >>>> both on uniqueness
>          >>>>      >      >> (something a zone ID potentially contributes toward)
>          >>>> and consistency across
>          >>>>      >      >> contexts (which a zone ID works directly against).
>          >>>> Now, arguably the identity
>          >>>>      >      >> of resources that are accessed by link-local URIs don't
>          >>>> need and cannot
>          >>>>      >      >> guarantee either property, but this is an example of
>          >>>> the sorts of problem that
>          >>>>      >      >> needs to be dealt with when local information is added
>          >>>> to a component that is
>          >>>>      >      >> critical to web security.
>          >>>>      >      >>
>          >>>>      >      >> For instance (2), in HTTP and several other protocols,
>          >>>> servers depends on the
>          >>>>      >      >> host component - as it appears in the URI - to
>          >>>> determine authority.  If there
>          >>>>      >      >> is no rule for stripping the zone ID from URIs, servers
>          >>>> hostname checks will
>          >>>>      >      >> depend on the client.  That exposes link-local servers
>          >>>> to information that they
>          >>>>      >      >> need to filter out.  Some might not be prepared to do
>          >>>> that.  Hostname checks
>          >>>>      >      >> are critical for security, especially the consistent
>          >>>> treatment of the field
>          >>>>      >      >> across different components like serving
>          >>>> infrastructure, web application
>          >>>>      >      >> firewalls, access control modules, and other components.
>          >>>>      >      >>
>          >>>>      >      >> This is a non-backwards-compatible change to RFC 3986.
>          >>>> The only issue related
>          >>>>      >      >> to this that is addressed in the draft is the question
>          >>>> of document management -
>          >>>>      >      >> this updates RFC 3986 - but surely there are other
>          >>>> concerns that might need to
>          >>>>      >      >> be addressed.  I see some effort to address software
>          >>>> backwards-compatibility in
>          >>>>      >      >> discussion threads, but I found very little in the
>          >>>> draft itself.
>          >>>>      >      >>
>          >>>>      >      >> The configuration of zones on a machine is could be
>          >>>> private information, but
>          >>>>      >      >> this information is being broadcast to servers.  In
>          >>>> HTTP, that is in Host
>          >>>>      >      >> header fields; on the Web, in document.location.  This
>          >>>> information might
>          >>>>      >      >> contribute significant amounts of information toward a
>          >>>> fingerprint.  I
>          >>>>      >      >> appreciate that the stripping of zone ID was never
>          >>>> implemented, but it is a
>          >>>>      >      >> useful feature.
>          >>>>      >      >>
>          >>>>      >      >> Arguments in Section 5 depend on the zone IDs being
>          >>>> hard to guess, but that
>          >>>>      >      >> isn't true.  Zone IDs are - in practice - low entropy
>          >>>> fields.  More critically,
>          >>>>      >      >> they are fields that are sent to servers.
>          >>>>      >      >>
>          >>>>      >      >> Zone ID size is not bounded - most implementations will
>          >>>> have a size limit on
>          >>>>      >      >> the authority or host portion of a URI (256 octets is
>          >>>> sufficient for current
>          >>>>      >      >> names), but the implication is that Zone IDs could be
>          >>>> arbitrary length.
>          >>>>      >      >>
>          >>>>      >      >> Though percent-decoding is not likely to be a concern
>          >>>> from a specification
>          >>>>      >      >> perspective (the operative specification from the
>          >>>> browser perspective does not
>          >>>>      >      >> apply pct-decoding to a v6 address [2]), what work has
>          >>>> been done to verify that
>          >>>>      >      >> a zone ID won't break existing software?
>          >>>>      >      >>
>          >>>>      >      >> [1]
>          >>>> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/> <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/>> <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/> <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/ <https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/>>>
>          >>>>      >      >> [2]
>          >>>> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser> <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser>>
>         <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser> <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser>>>
>          >>>>      >      >>
>          >>>>      >      >>
>          >>>>      >      >> --
>          >>>>      >      >> last-call mailing list
>          >>>>      >      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >>>>      >      >> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
>          >>>> <https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>>
>          >>>> <https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
>          >>>> <https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>>>
>          >>>>      >      >>
>          >>>>      >      >>
>          >>>>      >      >> _______________________________________________
>          >>>>      >      >> art mailing list
>          >>>>      >      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >>>>      >      >> https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>>>
>          >>>>      >      >
>          >>>>      >      > --
>          >>>>      >      > Prof. Dr.sc. Martin J. Dürst
>          >>>>      >      > Department of Intelligent Information Technology
>          >>>>      >      > College of Science and Engineering
>          >>>>      >      > Aoyama Gakuin University
>          >>>>      >      > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
>          >>>>      >      > 252-5258 Japan
>          >>>>      >
>          >>>>      >     _______________________________________________
>          >>>>      >     art mailing list
>          >>>>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>          >>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>          >>>>      > https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
>          >>>> <https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>>>
>          >>>>      >
>          >>>>      >
>          >>>>      >
>          >>>>      > --
>          >>>>      > https://LarryMasinter.net <https://LarryMasinter.net> <https://LarryMasinter.net <https://LarryMasinter.net>>
>          >>>> <https://LarryMasinter.net <https://LarryMasinter.net> <https://LarryMasinter.net <https://LarryMasinter.net>>>
>          >>>> https://interlisp.org <https://interlisp.org> <https://interlisp.org <https://interlisp.org>> <https://interlisp.org <https://interlisp.org>
>          >>>> <https://interlisp.org <https://interlisp.org>>>
>          >>>>      >
>          >>>>      >
>          >>>> --------------------------------------------------------------------
>          >>>>      > IETF IPv6 working group mailing list
>          >>>>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>          >>>>      > Administrative Requests:
>          >>>> https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>          >>>> <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>          >>>>      >
>          >>>> --------------------------------------------------------------------
>          >>>>
>          >>>>
>          >>>>
>          >>>> --
>          >>>> https://LarryMasinter.net <https://LarryMasinter.net> <https://LarryMasinter.net <https://LarryMasinter.net>>
>          >>>> https://interlisp.org <https://interlisp.org> <https://interlisp.org <https://interlisp.org>>
>          > --------------------------------------------------------------------
>          > IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]>
>          > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>          > --------------------------------------------------------------------
> 
> 
> 
>     -- 
>     https://LarryMasinter.net <https://LarryMasinter.net> https://interlisp.org <https://interlisp.org>
>     _______________________________________________
>     art mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/art <https://www.ietf.org/mailman/listinfo/art>
>