OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Created: (OBIX-129) 1.3 Non-Normative References CoAP-OBSERVE

1.3 Non-Normative References CoAP-OBSERVE

                 Key: OBIX-129
                 URL: http://tools.oasis-open.org/issues/browse/OBIX-129
             Project: OASIS Open Building Information Exchange (oBIX) TC
          Issue Type: Bug
          Components: REST Specification
    Affects Versions: REST PR02
         Environment: TAB Review
            Reporter: Toby Considine
            Assignee: Toby Considine

"1.3 Non-Normative References reads in part: 

CoAP-OBSERVE Hartke, K., ""Observing Resources in CoAP"", IETF Internet-Draft 08, February 25, 2013 

Found at: http://tools.ietf.org/search/draft-ietf-core-observe-08, expired: August 29, 2013. 

As noted elsewhere: 

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ""work in progress."" 

This expired reference being in Non-Normative references does not save it because it is used normatively at 3.3 Observing Resources: 

If an observed OBIX Object is updated a CoAP response message is sent to the client according to the CoAP-OBSERVE specification. 

There is a later version of this draft, https://datatracker.ietf.org/doc/draft-ietf-core-observe/, due to expire April 18, 2014. 

If an implementation conformed to version 8 of CoAP-OBSERVE, it would not conform to version 11 of CoAP-OBSERVE, as the change log clearly shows: 

Changes from ietf-10 to ietf-11: 

o Pointed out that client and server clocks may differ in their 
realization of the SI second, and added robustness to the existing 
reordering scheme by reducing the maximum notification rate to 
32768 notifications per second (#341). 

Changes from ietf-09 to ietf-10: 

o Required consistent sequence numbers across requests (#333). 

o Clarified that a server needs to update the entry in the list of 
observers instead of adding a new entry if the endpoint/token pair 
is already present. 

o Allowed that a client uses a token that is currently in use to 
ensure that it's still in the list of observers. This is possible 
because sequence numbers are now consistent across requests and 
servers won't add a new entry for the same token. 

o Improved text on the transmission of non-confirmable notifications 
to match Section 3.1.2 of RFC 5405 more closely. 

o Updated examples to use UCUM units. 

o Moved Appendix B into the introduction. 

Changes from ietf-08 to ietf-09: 

o Removed the side effects of requests on existing observations. 
This includes removing that 

* the client can use a GET request to cancel an observation; 

* the server updates the entry in the list of observers instead 
of adding a new entry if the client is already present (#258, 

o Clarified that a resource (and hence an observation relationship) 
is identified by the request options that are part of the Cache- 
Key (#258). 

o Clarified that a non-2.xx notification MUST NOT include an Observe 

o Moved block-wise transfer of notifications to [I-D.ietf-core- 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]