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

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

Hi URI Review team,

Thanks very much for your comments.  Ted, in answer to your question, I 
am not aware that this work has been presented to the IETF.  Stefan may 
do so if he wishes, and I would assist him if he wishes to see the work 
DISPATCHed.  Stefan, please take note that at least one reviewer here 
prefers the way you originally approached the work, and revise as you 
see fit.  Also, please take note of Martin's concerns below.

Eliot

ps: I will be unavailabe for the next two weeks.  Expect responses after 
that point.

On 11.04.2026 04:09, Martin J. Dürst wrote:
> Hello Eliot, others,
>
> One detail that caught my eye is in 
> https://www.ietf.org/archive/id/draft-grimminck-safe-ioc-sharing-08.html#name-step-3-host:
>
> >>>>
> IPv6 addresses use colon-hexadecimal notation inside square brackets 
> (e.g., "[2001:db8::1]"), which does not trigger auto-linking in 
> typical software; the entire bracket-enclosed literal, including any 
> dots within it (e.g., the dots in "::ffff:192.0.2.1"), MUST be left 
> unchanged.
> >>>>
>
> The part up to the semicolon is most probably true, but leaving this 
> unchanged would make it more difficult to fix that. We shouldn't put 
> additional blocks in front of IPv6 deployment and usage, even if they 
> are small.
>
> An additional comment below.
>
> On 2026-04-11 01:09, Ted Hardie wrote:
>> Hi Eliot,
>>
>> As a meta-question was this draft brought to the IETF before going to 
>> the
>> ISE?  I don't see any record of it in places I would expect (DISPATCH,
>> SAAG), but my records may be incomplete.
>>
>> After a quick read, this actually seems like something that the IETF 
>> should
>> consider, as there are some aspects of it that probably need wider 
>> review.
>> An example here is Section 9, which references how to handle IDNs.  It
>> describes punycode, but the overall IDNA standard should be referenced,
>> probably especially RFC 3490, Section 3.1.
>
> Which is obsoleted by RFC 5890.
>
> Regards,   Martin.
>
>> On the question related to the existing registration, RFC 7595 says:
>>
>>        There must not already be an entry with the same scheme name.  In
>>        the unfortunate case that there are multiple, different uses of
>>        the same scheme name, the Designated Expert can approve a request
>>        to modify an existing entry to note the separate use.
>>
>> I would first contact Hugo Salgado, the original registrant, to see 
>> if he
>> would be willing to work with this author on the draft and to 
>> transfer the
>> registration.  Since the use is functionally the same (though the
>> surrounding advice is different), I don't see a particular need to shift
>> the registration, but if this is desired and the original registrant is
>> unavailable, I believe the designated expert could invoke the clause 
>> above
>> and add the new document.
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Fri, Apr 10, 2026 at 4:38 PM Independent Submissions Editor (Eliot 
>> Lear)
>> <[e-mail]> wrote:
>>
>>> Dear URI reviewers,
>>>
>>> The Independent Submissions Editor has received a publication 
>>> request for
>>> draft-grimminck-safe-ioc-sharing.  This draft intentionally makes 
>>> certain
>>> URIs unresolvable during transport.  I am contacting you because 
>>> there are
>>> several legacy use cases, two in particular: http-> hxxp and https ->
>>> hxxps.  I have no doubt, but that these indicators of compromise (IOC)
>>> transformations are widely accepted as a convention.  I note that an 
>>> old
>>> draft, draft-salgado-hxxp-01 has provisionally registered these 
>>> schemes.
>>> This is sufficient to limit damage with those particular schemes.  
>>> There
>>> can be other schemes that may be used to reference compromised content.
>>>
>>> I have several questions for this group:
>>>
>>>     - Stefan is considering a more generic approach that uses illegal
>>>     characters in the scheme (*) for other schemes.  Do you agree 
>>> that is
>>>     appropriate?
>>>     - Would you like the registration for hxxp and hxxps to move to 
>>> this
>>>     work, should it progress?
>>>     - Would you like to mark the registrations as permanent as part of
>>>     that process?
>>>     - Would you like to perform a review of the draft? Reviewer 
>>> guidance
>>>     can be found at 
>>> https://www.rfc-editor.org/materials/reviewer.guide.txt
>>>     .
>>>
>>> Regards,
>>>
>>> Eliot
>>>
>>>
>>> _______________________________________________
>>> Uri-review mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>>
>> _______________________________________________
>> Uri-review mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>