On 2021-07-05, at 20:16, Michael Richardson wrote:
>
>
> https://www.iana.org/assignments/cose/cose.xhtml#header-parameters
Is there a time-warp somewhere?
x5bag (TEMPORARY - registered 2019-08-20, extension registered 2020-07-28,
expires 2021-08-20) 32 COSE_X509 An unorde
On 5. Jul 2021, at 23:55, Michael Richardson wrote:
>
> https://www.ietf.org/archive/id/draft-ietf-cose-x509-08.html#Tags
>
> Does not say anything about the allocation, and it's clearly been more than
> two revisions of the document since 2019.
Reinforces the point that only IANA and IESG shou
On 2021-07-16, at 03:06, Toerless Eckert wrote:
>
> Iotops is another solution
> group,
Actually No.
From their charter [1]:
> Revision, updates, and extensions to work from existing WGs will be done in
> those WGs. Where new work may be needed, IOTOPS will help identify candidate
> venues
On 20. Jul 2021, at 23:19, Toerless Eckert wrote:
>
> Optional parameters: cose-type
Ugh.
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
On 2021-07-21, at 09:58, Esko Dijk wrote:
>
> If the object is created to be transported over other ways (e.g. email, USB
> stick, etc) then I would opt for including that 'content type' possibly.
Probably not needed:
https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-02.html#name-cbor
We had interesting discussions yesterday about how to fix the media-type and
content-format registrations for CBOR-based anima vouchers.
I’m growing a bit tired of dispensing the ancient wizardry that is required
each time such a registration is needed, so I started writing it up:
https://cabo.
.)
Grüße, Carsten
> On 2021-07-21, at 14:04, Carsten Bormann wrote:
>
> On 2021-07-21, at 09:58, Esko Dijk wrote:
>>
>> If the object is created to be transported over other ways (e.g. email, USB
>> stick, etc) then I would opt for including that 'content t
On 2021-07-21, at 18:27, Toerless Eckert wrote:
>
> I find it architecturally somewhat weird to have this "level skip”:
Depending on the key and its usage, you may want to include the context in the
signing input that this is a voucher. So that would support Toerless’ unease.
Grüße, Carsten
>
>> https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html
>
>> Comments and PRs very welcome.
>
> I did find reading it invoked a new appreciation for Arcane Wizardry.
>
> Specifically, I found that sections 3 and 4 didn't tell me anything that I
> recognized as
>
>> Now, there is in the COSE header also a parameter paramaeter called "content
>> type"
>
> In my implementation I don't use the 'content type' header in COSE because it
> is duplicate.
It is not: the REST-level (here CoAP) Content-Type is the media-type of the
whole thing (as packaged in
Time for me to update the coaping gem…
Well, yeah, the warning message.
Grüße, Carsten
$ gem install coaping
Fetching coaping-0.0.1.gem
Successfully installed coaping-0.0.1
$ coaping coap.me
Trying 20 times with coap.me at port 5683, waiting 1.0 second max:
/Volumes/nar/Users/cabo-rescue/lib/ru
On 2021-07-22, at 09:45, Carsten Bormann wrote:
>
> Time for me to update the coaping gem…
Done:
VERSIONS:
• 0.0.2 - July 22, 2021 (5 KB)
• 0.0.1 - November 19, 2012 (4.5 KB)
Grüße, Carsten
___
Anima mailing list
Anima@ie
On 2021-07-22, at 10:23, Esko Dijk wrote:
>
> be liberal in what it accepts
Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
somebody might decide to do something different from the standard, so I’ll
implement my idea of what that could be). If it says you need to
> On 2021-07-21, at 21:36, Michael Richardson wrote:
>
> Signed PGP part
>
> Esko Dijk wrote:
>> There is already a "CoAP ping" described in RFC 7252 that can be
>> used. It does not access any resource, just the CoAP server endpoint at
>> CoAP message layer. As a side effect of this ping you
> Yes I read the IETF specs and then implement my idea of what these are trying
> to say. It helps if more people are looking at it, as we do in this case :)
> to avoid interpretation errors.
> From what I read, a COSE_Sign1 object can be adequately described by cf=18 so
> that's what I implem
On 2021-07-22, at 22:55, Michael Richardson wrote:
>
> Signed PGP part
>
> Toerless Eckert wrote:
>> So: if we wanted to support the COSE content-type field semantically
>> correctly, we should ask for another registry entry:
>
>> application/voucher-cbor TBD4
>
> I don't understand what that wou
> Overthinking is a result of underspecification in the COSE RFC/bis-draft.
This is not underspecification; this is leaving decisions to the protocol using
COSE. I am trying to get you to make those decisions.
> Constrained vouchers (application-type/voucher-cose+cbor, TBD3) SHOULD NOT
> use
On 17. Dec 2021, at 23:04, Brian E Carpenter
wrote:
>
> I agree that it isn't worth updating the RFC for this.
+1
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
On 2022-03-18, at 15:44, Rob Wilton (rwilton)
wrote:
>
> 3. Sec 4.
>in an LLN mesh can be
>
> LLN doesn't seem to be defined anywhere.
It is “defined” in RFC 7102.
(I would not use this term.
It has the definitional sharpness of Labskaus.)
The term “LLN mesh” is definitely not defined.
Hi Sabrina,
I looked at the registration requests in the draft.
They use somewhat unusual language about discovering ports - resource discovery
is understood to discover resources. For brski.jp, this appears to be about
discovering a CoAP or CoAPs entry point (without describing how exactly tha
>
> If we had known that we'd spend 2 years in the RFC-editor Q waiting for
> DTLS1.3, then maybe we would have done the document differently.
>
>> Except that neither one works for L3 networks multicast IMHO (i am getting no
>> response to that request i sent meaning at least nobody knows or car
> Andy Bierman wrote:
>> I am not in favor of the YANG-CBOR draft defining special encodings for
>> 1 derived type (like date-and-time). Implementations may not store the
>> named YANG typedefs defined in various YANG modules.
>> The current draft (properly) addresses only the base types, not der
On 2022-06-28, at 22:22, Andy Bierman wrote:
>
> During operation, the optimized encoding is used for any objects with the
> data type. E.g., tag X for date-and-time, tag Y for ipv4-address, tag Z for
> ipv6-address.
> The receiver is responsible for converting the special encoding to the
> co
On 2022-06-28, at 22:50, Carsten Bormann wrote:
>
> The alternative would be to trigger on the data, so any string that looks
> like 2022-06-28T20:48:15Z would turn into 1(1656449295). That has some
> interesting security considerations, though.
Hmm, that is starting to
On 2022-06-28, at 23:30, Andy Bierman wrote:
>
> A safer approach would be to add some info to the SID 'item' entry.
> This has to be done for every data node using the alternate tag.
> This 'manual' approach can be done many different ways.
The tool that generates the SID file could be paramete
> On 29. Jun 2022, at 03:54, Jürgen Schönwälder
> wrote:
>
> On Tue, Jun 28, 2022 at 11:40:55PM +0200, Carsten Bormann wrote:
>> On 2022-06-28, at 22:50, Carsten Bormann wrote:
>>>
>>> The alternative would be to trigger on the data, so any string that
> So your proposal is for the sender to check every single string it sends to
> the receiver to
> see if some complex 20 byte string can be changed to an 8 byte integer
> instead?
In an actual implementation, these 20 byte strings never exist.
How a sender finds out that the 4-byte integer is
On 29. Jun 2022, at 19:10, Andy Bierman wrote:
>
> The sender and receiver need to agree on the encoding of each schema item.
> There can be no guessing. But maybe this is a protocol issue and can be
> addressed there.
Yes. E.g, the constrained-voucher spec could define a new media type,
ZAN
>
> Yes. E.g, the constrained-voucher spec could define a new media type,
> ZANG-data+CBOR, which is defined to be almost identical to YANG-data+CBOR,
> except that in a few places (small matter of defining this properly, e.g.,
> based on SIDs) the encoding deviates.
>
>
> There will be more
>
>> We can do the same for date fields, e.g.
>> "created-on" -> "created-on-epochtime"
>> "expires-on" -> "expires-on-epochtime"
>
> I don't mind doing this.
> Does it establish some precedent that others may dislike?
I don’t think there is anything with bespoke formats.
The need to do somethin
On 2022-07-06, at 20:14, Laurence Lundblade wrote:
>
> By RFC 9052:
> ? 4 => bstr,; key identifier
>
> which says kid is either entirely absent
(i.e., both the 4 and the byte string are absent, which they can be because the
entry was marked with a ?, which is a shortcut for 0*1, ze
On 2022-07-06, at 20:02, Carsten Bormann wrote:
>
> I don’t think there is anything with bespoke formats.
➔
I don’t think there is anything *WRONG with bespoke formats.
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ie
(Resending with CC:)
On 2022-08-03, at 02:25, Toerless Eckert wrote:
>
> downrev
I think you mean downref.
8366 would have 7950 as downref.
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
> In GRASP (RFC8990] we define the GRASP message structure as follows:
>
> message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]
>
> MESSAGE_TYPE = 0..255
> session-id = 0..4294967295 ; up to 32 bits
> grasp-option = any
>
> Then we've defined a few MESSAGE_TYPEs of which the
On 2022-08-19, at 23:05, Brian E Carpenter wrote:
>
>>> EXTENSION_TYPE = 0..255
>> There is no reason to limit this to 255.
>> ➔ EXTENSION_TYPE = uint
>> (Do you plan to creat a registry for these?
>
> The 'extension_type' terminology is confusing, because these would
> be new GRASP options, and
>
> Aka: grasp-option can not represent the purely numeric ttl anymore.
>
> We could do a one-off fix for ttl by channging message-structure, but
> i really don't see why we would want to constrain grasp-option to be
> less than any, see below.
Correct.
Grasp-option really is the lower layer of
On 2022-08-23, at 13:27, Derek Atkins wrote:
>
>tcp-header = {seq: uint, ack: uint, * $$tcp-option}
Right. For the full set of extensibility, today we’d probably say:
tcp-header = {seq: uint,
ack: uint,
* $$tcp-option,
* label .feature "U
On 2022-08-23, at 14:27, Toerless Eckert wrote:
>
> How about any of this in array context ?
message = [foo, bar, +baz, *option]
option = known-option / [label .feature "Unrecognized Option", *any]
known-option = $option .within ([label, *any])
; replace by meaningful definitions:
$option /=
On 2022-08-24, at 19:20, Toerless Eckert wrote:
>
> data-to-be-signed = [session-id, initiator, ?locator-option, objective ]
That is getting closer to my question “what does it mean for (something) to be
signed”?
Apparently, this is a statement from an initiator, valid within the session-id,
On 2022-08-31, at 16:29, Behcet Sarikaya wrote:
>
> What is wrong with an umlaut for a German person?
This is a bit off-topic, but the answer is: Nothing.
Toerless’ email system is just famously stuck in the early 1990s, so a simple
beyond-ASCII Latin character creates a challenge for it.
G
On 2022-10-26, at 16:57, Esko Dijk wrote:
>
> I'm not 100% sure if for a resource at the root (/), one Uri-Path Option with
> 0 length is needed or if 0 Uri-Path Options can be used. Or if both methods
> would be valid.
That is a well-known idiosyncracy in the URI format.
Have a look at:
htt
> On 2022-10-26, at 19:39, Michael Richardson wrote:
>
> So, no Uri-Path option is equivalent to /?
Actually, to
coap://foo
and
coap://foo/
For contrast, note that
coap://foo?
and the equivalent
coap://foo/?
actually have a single empty Uri-Query Option, but
On 2022-10-27, at 19:57, Toerless Eckert wrote:
>
> next hop
??
I thought we were in a thread about Uri-Path.
(If this is indeed a reverse proxy, that gets to choose the paths it supports;
I don’t know what paths the actual registrar would use — sorry for not
following all the discussion here
On 2022-11-24, at 17:02, Jan Lindblad (jlindbla)
wrote:
>
> If any of this causes problems with SID generation, I'm afraid that's not my
> territory. :-)
I think it would be good if there were sx:structure support in PYANG that we
can use.
(Which still may not be your territory…)
Grüße, Cars
> I think you did this manually, right?
Yes. To my best understanding of YANG and YANG-JSON.
(E.g., I needed to find out how to represent empty lists in YANG-JSON — this
was recently (2022!) still a discussion point on the mailing list, which needed
the author of RFC 7951 to resolve [1]...)
[
On 2023-02-25, at 22:52, Carsten Bormann wrote:
>
>> RFC8366.
>
> Good idea. Let’s see when I get to it…
Examples don’t validate.
>> Base64.strict_encode64(Base64.decode64("base64encodedvalue=="))
=> &quo
On 2023-02-25, at 23:21, Carsten Bormann wrote:
>
> Examples don’t validate.
Patchup script included.
(But errata not yet submitted.)
https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-01.html#name-rfc-8366
Grüße, Carsten
___
On 2023-02-26, at 00:02, Michael Richardson wrote:
>
> Thank you... but the YANG still went through your brain, not a tool :-)
> So, I'm still concerned that the content might be wrong in some way that
> deceives our brains.
Yep, somebody SHOULD write that tool.
(Hmm, need to find a BYGS [bright
https://datatracker.ietf.org/doc/pdf/draft-ietf-cbor-cddl-control-07
Sent from mobile, sorry for terse
> On 18. Jul 2023, at 17:38, Michael Richardson wrote:
>
>
> In the JWS I-D, we have some JSON that is an example.
> And the content within is BASE64URL encoded.
> We could, I think, describ
On 19. Jul 2023, at 03:41, Carsten Bormann wrote:
>
> https://datatracker.ietf.org/doc/pdf/draft-ietf-cbor-cddl-control-07
Apologies, that was the previous one, now RFC 9165.
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-more-control/
We have .b64u and .json; maybe these need
On 18. Jul 2023, at 17:38, Michael Richardson wrote:
>
>
> In the JWS I-D, we have some JSON that is an example.
> And the content within is BASE64URL encoded.
> We could, I think, describe this in CDDL, but we aren't trying to be
> authoritative. (It's a JOSE example)
OK, CDDL describes possib
> Aka: we do have a pretty successful history with make-it-up-as-you-go
> (in)formal specifications.
Yes. But I wasn’t asked how to do this wrong, but how to do this right.
Probably because the issue is not specific to that one use case.
(As I wrote, this is not about CDDL, it is about steali
On 20. Jul 2023, at 00:57, Michael Richardson wrote:
>
> Esko Dijk wrote:
>> * Is application/voucher-cose+cbor a correct name?
Yes.
Whether a coucher+cose would be more desirable, I don’t have an opinion on.
If it is, please do request the registration.
Firing off a request to a random maili
On 2023-07-23, at 06:48, Michael Richardson wrote:
>
> the manufacturer has all the golden values (the endorsements).
The manufacturer may have the reference measurements.
Whether anyone whose statements you are willing to base your authorization on
is willing to endorse the manufacturer’s clai
On 25. Jul 2023, at 15:07, Michael Richardson wrote:
>
> I have resisted suggestions that we put an array for the objective-value, and
> also that it have a string that needs to be parsed like
> "mode=prm,foo=1,bar=2"...
You give a good reason not to do this at all.
But if you want to do this,
>
>> objective-value = text ; name of the supported protocols.
>> ; e.g., "EST-TLS" for RFC 7030.
Doesn’t pass semantic parser — one name for all protocols?
(What is the single name of all the people in the room?)
Do you want:
>> objective-value = text ;
On 2. Aug 2023, at 05:40, Brian E Carpenter wrote:
>
> In CDDL, {...} is called a map, in Python and JSON it's called a dictionary.
(In JSON, it is called an object. In Ruby, it’s called a Hash. In Erlang,
it’s called a Map. Etc.)
> [...] is an array (a.k.a. list).
> So mainly the {...} isn
Answer:
No.
> The pattern in NETMOD and OPSAWG in publishing documents with YANG modules
All the current practices around YANG center on YANG models describing
management information bases on servers (data at rest).
8366bis is about messages (data in flight). Most of the current practices lose
On 17 Nov 2016, at 19:10, Eliot Lear wrote:
>
> Also, we're wondering what effort it would be to move to CBOR for
> transactions.
Moving from JSON to CBOR is zero effort if you just do it to gain runtime
efficiency or use the better datatypes.
If you want to use the last bit of on-the-wire eff
> On May 18, 2017, at 20:27, Michael Richardson wrote:
>
>
> So, this proposes to use CBOR to "compress" JSON, preserving JWT/JOSE
> signatures, rather than using CWT. I'm not sure what I think of this as yet.
My summary: JSCN is great if you actually *have* to process
JOSE-signed/-encrypted
Leaving the registry for later sounds fine to me, in particular if it isn’t
clear yet what the registration policy should be.
If we ever add not-over-IP “transports”, there might be a need for experiments
before we go registering.
So I would probably identify a range of numbers that are strictly
r now and carving out a range of
that for experimental.
Grüße, Carsten
> On May 30, 2017, at 22:53, Michael Richardson wrote:
>
>
> Carsten Bormann wrote:
>> If we ever add not-over-IP “transports”, there might be a need for
>> experiments before we go registering. S
On Jun 9, 2017, at 22:43, Brian E Carpenter wrote:
>
> But if not, *somebody* is going to replicate the packets. If the VRF
> doesn't do it, GRASP itself will have to do it. That doesn't seem optimal
> to me.
I wonder why you are saying this.
Generally, where information needs to be disseminate
On Nov 29, 2017, at 12:35, Sheng Jiang wrote:
>
> During the IETF100, there was a consensus that draft-liu-anima-grasp-api is
> fully consistent with the current ANIMA charter, under the condition it
> intends to be an Informational document. After the meeting, the authors have
> updated the d
Hi Michael,
2.2.2 says:
It is not an error if a name is first used with a "/=" or "//="
(there is no need to “create it" with "=").
The intention is indeed to say that no initial rule with a “=“ is needed.
Any ideas how we can clarify this some more?
You could also make use of the convent
On Sep 11, 2018, at 22:25, Michael Richardson wrote:
>
> SHOULD ietf-core-sid say something about this?
Yes, we should have a common way of handling SID allocations in RFCs.
draft-ietf-core-sid sounds like a natural way to place this, but what goes into
what document is often a question of who
nce of (part of) the comi.space by a organisation like IANA could be
> a possibility.
>
> Peter
> Andy Bierman schreef op 2018-09-12 01:32:
>
>>
>>
>> On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann wrote:
>> On Sep 11, 2018, at 22:25, Michael
On Jun 12, 2019, at 19:26, Julian Reschke wrote:
>
>> 2) Assuming the answer to (1) is no, what should we make of RFC7030
>>that says to use it, and to base64 binary objects?
>
> Raise an erratum :-).
Not sure about the smiley here. This is an erratum.
Now how to resolve this depends on wh
On Jul 17, 2019, at 19:10, Michael Richardson wrote:
>
> always base64 the payloads
Which means that the content-type headers lie.
Backwards combyativbility [actual autocorrect result :-)] can be nasty.
But sniffing this out should be easy.
Grüße, Carsten
__
On Aug 8, 2019, at 20:21, Toerless Eckert wrote:
>
>> 5:00 pm - 6:00 pm Thursday, Aug 29 2019 (UTC+01:00) Amsterdam, Berlin,
>> Bern, Rome, Stockholm, Vienna
>
> And webex continues to confuse me,
Webex is just following the great tradition of certain other widely used
calendaring tools: foist
> On Oct 22, 2019, at 16:48, Michael Richardson wrote:
>
> Signed PGP part
>
> In answering DISCUSSes on BRSKI, I came up the question of do the
> YANG-serialization-to-JSON rules specify which base64 (original
> or urlsafe) encoding is to be used for “binary" types?
Legacy (RFC 4648 Section 4
On 2020-04-28, at 00:14, Michael Richardson wrote:
>
>> I'm quite sure the early aassignments were announced on the list, but
>> when I forget what values were pre-assigned I just go and look at my
>> code:
>
> I thought that early allocations were supposed to go into the document so
> they don'
On 2020-06-27, at 09:57, Erik Andersen wrote:
>
> There certainly is a big difference between the term certification (an act)
> and the term certificate (a data value). Certification implies that the CA
> does some validation before issuing a certificate.
Well, I maybe have a different percepti
On 2020-06-27, at 09:57, Erik Andersen wrote:
>
> certificate authority
4 matches in 1id-abstracts.txt.
7292 files on my laptop happen to match.
Enjoy how RFC 4523 dances right into the fire here:
( 2.5.6.16 NAME 'certificationAuthority'
DESC 'X.509 certificate authority'
On 2020-11-30, at 14:01, Esko Dijk wrote:
>
> without using core-multipart
Why not?
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
I’m looking at this from my phone, but I think Michael is right.
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]
Says each pair of objective and locator-option/empty should be packed into its
own array.
It could have said
You forced me to get a bigger screen...
I don’t know what you are trying to say here:
> On 13. Dec 2020, at 20:43, Michael Richardson wrote:
>
> I guess I'm still confused by why this is:
> [ [objective1],[locator2-option], [objective2],[locator2-option],...]
>
> and not:
> [ [objective1, lo
On 13. Jun 2021, at 04:22, Michael Richardson wrote:
>
> "another web origin" --- I guess I don't know what this means.
See RFC 6454 "The Web Origin Concept”.
In short, scheme + authority.
> Does it mean redirecting from https://one.example/foo to
> https://two.example/bar,
Different orig
On 14. Jun 2021, at 03:09, Michael Richardson wrote:
>
> 1) how to process yang files with -DD-MM into XML.
> 2) how to generate yang tree files.
> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
> 4) how to do this with MT Makefiles?
I people could tell me what
> One possibility is that kramdown-rfc ought to look for, and include the
> latest foo--MM-DD.yang file, when told to ::include foo.yang.
> Alternatively, it could perhaps do the -MM-DD substitution itself.
How about
{::include foo--??-??.yang}
and, if there is no such file, kramdown
I can’t help you with your dark desires to use XML, but I would propose the
following fix for that:
— use xi:include or src= for the XML source (I forget which one works), with a
static name
— simply generate a symlink from the most recent .yang to the static name in
the Makefile
— use --expand
On 2021-06-14, at 18:26, Michael Richardson wrote:
>
>cb> How about
>
>cb> {::include foo--??-??.yang}
>
>cb> and, if there is no such file, kramdown-rfc expands the wild card in
>cb> the directory and uses the numerically latest file?
>
> You'd use shell globs?
Yes. Any
On 2021-06-14, at 19:31, Michael Richardson wrote:
>
> (I continue to argue that COSE-signed-CBOR will be better if doing things
> over native BTLE)
What is stopping you from fixing this?
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https://w
On 24. Jun 2021, at 05:55, Michael Richardson wrote:
>
> If someone creates an implementation of this document using a SID-aware,
> YANG-driven code generator, then they had better use the values in the
> document, not the the values derived through the yang-sid process.
> (Or they'd better check
Hi Esko,
I don’t think we can use YANG to insert a “Plain-old-CBOR” (PoC) data item into
the voucher.
The objective of the YANG stand-in proposal [1] is to address this space, but
initially with a different approach and solution. Maria is pursuing a way that
would make PoC insertion from a YA
On 2025-03-11, at 17:48, Esko Dijk wrote:
>
> • Register a new SID number with IANA using a new tbd procedure (which
> we’re considering for RFC8366-bis now). This number would be outside the
> “voucher” module range which is controlled by IETF.
In the YANG world, you need to have a modu
On 12. Mar 2025, at 11:23, Esko Dijk wrote:
>
> I see a need for multiple levels of extendibility of a voucher /
> voucher-request:
>
> 1) new attributes in a standardized way (e.g. defined by IETF or others,
> vendors themselves). We are looking for a method of extending that's easier
> than
> These are reasonable points.
> CoAP has congestion control, retransmissions, block-mode,... which are all
> the things that TCP was doing for us. Re-inventing that would be silly.
> So either all CoAP, or no-CoAP.
>
>> 2.2 However, i very much would like to re-use the CoAP "messaging model",
On Jul 22, 2025, at 07:41, Toerless Eckert wrote:
>
> My URLs are /.well-known/ctrl/0 or /.well-known/ctrl/1 to switch on/off
Why?
/.well-known is for finding out something about a server that you don’t know
much about.
It is not for operational use.
Grüße, Carsten
__
Yes, that idea came up a lot already.
The reason we haven’t acted on that is that higher option numbers sort later,
so there is some work to be done to get the components of the URI in order.
Apart from that: Uri-Patj(".well-known”) as a CoAP Option would save 10+ bytes
on each use, so indeed let
90 matches
Mail list logo
