Draft: draft-ietf-core-resource-directory

Commentary: This addresses . The net effect on word / line count is not large ( saving ~60 lines and ~150 words ) , but it 's less repetitive and IMO gives better guidance towards how to handle errors . Will merge into -20 today unless objected to . 
 The entries for " Failure " are quite repetitive for 4.00 and 5.03 . Can we factor these out a bit ? The entry " HTTP support " is surprising ; maybe this item should be explained beforehand . ( It seems all it is saying is that HTTP does not do multicast or /.well - known / core ? ) ( via Jaime ) 
 and AFAIR both of you argued for the interaction templates in the length they have now , but I failed to find the old arguments . ( There were some unresolved points in and and , but they do n't tell the whole story ) . I 'd argue that most of the failure codes can be removed , for they ca n't be exhaustive anyway ( would we need to add 4.01 for when the client would need to authenticate ? 4.08 if a block was missed ? 4.29 to throttle ? ) – handling those is part of CoAP and not the application . If I were to make a proposal , I 'd replace all " Failure : " paragraphs ( except 4.04 on update / removal , as that 's particularly noteworthy ) with a general note that Are the sections still justified to be that long , and if so , could you contribute a note on why that is for the review of ? 
 A point I missed that should go after that suggested paragraph , to fully cover  's comment : 
 I have made no contribution to template length or format . I do n't remeber arguments that support their length . Having written that , I like to idea of having templates . I like them to be stand - alone which makes them lengthy . I have enormous problems with the response codes . Their text never covers what you want to express , they remain approximations of the problem unless they are at the general server level . My sugesstion is not change what is there , but I will not oppose the general text although I consider it possibly too vague for standardization .
Paragraph (version A):
If the registration fails with a Service Unavailable response and a
Max-Age option or Retry-After header, the registering endpoint SHOULD
retry the operation after the time indicated.  If the registration
fails in another way, including request timeouts, or if the Service
Unavailable error persists after several retries, or indicates a
longer time than the endpoint is willing to wait, it SHOULD pick
another registration URI from the "URI Discovery" step and if there
is only one or the list is exhausted, pick other choices from the
"Finding a Resource Directory" step.  Care has to be taken to
consider the freshness of results obtained earlier, e.g. of the
result of a "/.well-known/core" response, the lifetime of an RDAO
option and of DNS responses.  Any rate limits and persistent errors
from the "Finding a Resource Directory" step must be considered for
the whole registration time, not only for a single operation.
Paragraph (version B):
If the registration fails, including request timeouts, or if delays
from Service Unavailable responses with Max-Age or Retry-After
accumulate to exceed the registrant's configured timeouts, it SHOULD
pick another registration URI from the "URI Discovery" step and if
there is only one or the list is exhausted, pick other choices from
the "Finding a Resource Directory" step.  Care has to be taken to
consider the freshness of results obtained earlier, e.g. of the
result of a "/.well-known/core" response, the lifetime of an RDAO
option and of DNS responses.  Any rate limits and persistent errors
from the "Finding a Resource Directory" step must be considered for
the whole registration time, not only for a single operation.
Paragraph (version A):
If the registration update fails with a "Service Unavailable"
response and a Max-Age option or Retry-After header, the registering
endpoint SHOULD retry the operation after the time indicated.  If the
registration fails in another way, including request timeouts, or if
the time indicated exceeds the remaining lifetime, the registering
endpoint SHOULD attempt registration again.
Paragraph (version B):
If the registration fails in any way, including "Not Found" and
request timeouts, or if the time indicated in a Service Unabailable
Max-Age/Retry-After exceeds the remaining lifetime, the registering
endpoint SHOULD attempt registration again.