[Uri-review] Re: draft-grimminck-safe-ioc-sharing

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Stefan,

I'm pretty happy with what I'm seeing.  A few remaining nits:

  * The IANA considerations isn't still quite nailed down, and this has
    to be finished before going to the IESG for review.  There are two
    choices:
      o Do not ask for re-assignment of hxxp or hxxps, in which case you
        should empty IANA considerations and replace it with ["RFC
        Editor to remove this section"] and "No IANA actions are required".

        OR

      o You may ask the IANA to reassign those two schemes to this
        draft.  At the least you should contact the original assignee. 
        If there is agreement, this should be a pretty easy thing.  You
        may also ask for a permanent allocation, but the process will
        get dragged out.

  * Please could you add a statement in your introduction that this
    informational specification is not a Internet standard, nor does it
    have community consensus?  If you want this to be a standard, and
    Ted suggested that might be a good route, we could see about that
    with the IETF.
  * Please consider adding acknowledgments for those who provided feedback.

I've asked for one additional commissioned review, but if that doesn't 
happen, we'll move one.

Eliot

On 28.04.2026 10:31, Stefan Grimminck wrote:
> Hi Eliot, Martin, and URI-review team,
>
> Thank you again to everyone for the review of -08. I have published -09 incorporating the feedback from this thread:
> https://datatracker.ietf.org/doc/draft-grimminck-safe-ioc-sharing/09/
>
> The main changes:
>
> 1. IPv6 literals are now obfuscated (Step 3). Colons inside an IPv6 literal become "[:]", and any embedded IPv4 dots become "[.]". The outer brackets of an IP-literal are preserved because removing them would break RFC 3986 authority syntax.
> Examples:"http://[2001:db8::1]:8080" becomes "[http]://[2001[:]db8[:][:]1]:8080"; bare "2001:db8::1" becomes "2001[:]db8[:][:]1".
> 2. The IDNA edge-case text in Section 9 now cites RFC 5890 explicitly.
> 3. The "does not trigger auto-linking" justification for leaving IPv6 untouched has been removed.
>
> To validate the spec against real-world URL shapes, I built a Go reference implementation and ran it against the Web Platform Tests URL corpus (879 inputs):
> https://github.com/StefanGrimminck/safeioc
>
> CI run (per-item audit trail, see TEST section):
> https://github.com/StefanGrimminck/safeioc/actions/runs/24891319062/job/72884133848
>
> Thanks again, and looking forward to next steps.
>
> Best regards,
>
> Stefan Grimminck
>
>
>
> On Saturday, April 18th, 2026 at 13:25, Stefan Grimminck<[e-mail]> wrote:
>
>> Hi Martin,
>>
>> Thank you for the TR58 reference. Initially, I set out to codify existing behaviors, but it became clear that a lot of legacy mechanisms do not scale (e.g., character substitution). This led to documenting a path forward with the scheme bracketing seen in the current text.
>>
>> I agree that this should include IPv6 to ensure consistency. It was initially omitted due to the currently low frequency of IPv6 occurrences and the existing use of brackets within IPv6 syntax. I am creating a test setup to validate a solution for IPv6 and will share results.
>>
>> Best regards,
>>
>> Stefan Grimminck
>>
>>
>> On Tuesday, April 14th, 2026 at 11:00, Martin J. Dürst<[e-mail]> wrote:
>>
>>> Hello Stefan,
>>>
>>> First, please also have a look athttps://www.unicode.org/reports/tr58/,
>>> which may be relevant for your work.
>>>
>>> On 2026-04-13 18:33, Stefan Grimminck wrote:
>>>
>>>> Based on the review feedback, I'm planning the following changes for -09:
>>>> - Reframing the IPv6 rationale in Step 3. The text currently states that IPv6 "does not trigger auto-linking in typical software," which I agree should not be presented as a permanent justification. I plan to replace this with a technical rationale.
>>> Sorry to disagree, but this is NOT about justification. Why do you
>>> obfuscase domain names and IPv4 literals, but not IPv6 literals? If
>>> attacks with the former are possible, I'm sure attacks with the later
>>> also should be possible, and obfuscation has to address this.
>>>
>>> Regards,    Martin.
>>>
>>>
>>>