Re: [art] Re: Alternative representation of URIs in YANG

Hello Tom, others,

Many thanks to Tom for providing the pointer to the 'uri' datatype in 
RFC 6021. That suggests to me that one of the questions that should be 
answered is whether the decomposition is needed at all.

Also, with respect to the name, instead of 'ietf-uri', 'decomposed-uri' 
or 'uri-decomposition' may be more appropriate.

Regards,   Martin.

On 2025-11-30 00:16, tom petch wrote:
> From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
> Sent: 25 November 2025 23:26
> 
> I'm copying the URI list and the URI review list to make sure URI
> experts can have a look at this and comment.
> 
> My knowledge about YANG is essentially zero, but it seems somewhat
> surprising to me that this would be the first time URIs would turn up in
> YANG.
> 
> <tp>
> 
> I am not sure what you are referring to but URI is a defined datatype in RFC6021 from 2014 which in turn is based on the TC-MIB from an earlier language.
> 
> Tom Petch
> 
> Regards,    Martin.
> 
> On 2025-11-25 07:38, Kent Watsen wrote:
>>
>> The immediate expected usage is for HTTP URIs.  That said, the module aims to be as generic as possible, so alternate uses may arise.
>>
>> I'm didn't know "ietf-uri" was perhaps too broad a name.  Please suggest an alternate name if that makes sense.
>>
>> Kent // author
>>
>>
>>
>>
>>> On Nov 24, 2025, at 5:01 PM, Martin Thomson <mt@lowentropy.net> wrote:
>>>
>>> Hi,
>>>
>>> I recently had cause to review draft-ietf-netconf-http-client-server and found Section 2 [2] gave me pause.
>>>
>>> This section claims to represent URIs with a name of "ietf-uri" for the module.  However, it seems like the only form on offer is a very specific authority form.  This might be sufficient for HTTP URIs, but I doubt it works for SIP, file, or many other URI forms.
>>>
>>> Questions:
>>>
>>> * I know that decomposition is common when using specific types of URI, but is this a sensible way to represent URIs?
>>> * Should this instead try for a more limited scope?  Through a different name, perhaps.
>>>
>>> Kent, on CC, can likely answer questions about expected usage.
>>>
>>> Cheers,
>>> Martin
>>>
>>> [2] https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server#section-2
>>
>> _______________________________________________
>> art mailing list -- art@ietf.org
>> To unsubscribe send an email to art-leave@ietf.org

Received on Monday, 1 December 2025 04:26:50 UTC