Add in RFC number for JMAP Core references

spec/calendars/calendar.mdown

@@ -61,14 +61,14 @@ A **Calendar** object has the following properties:
 
 ## Calendar/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1. The *ids* argument may be `null` to fetch all at once.
+Standard "/get" method as described in [@!RFC8620] section 5.1. The *ids* argument may be `null` to fetch all at once.
 
 ## Calendar/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2.
+Standard "/changes" method as described in [@!RFC8620] section 5.2.
 
 ## Calendar/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3.
+Standard "/set" method as described in [@!RFC8620] section 5.3.
 
 A calendar MAY be deleted that is currently associated with one or more events. In this case, the events belonging to this calendar MUST also be deleted. Conceptually, this MUST happen prior to the calendar itself being deleted, and MUST generate a **push** event that modifies the state of the *CalendarEvent* type for the account.

spec/calendars/calendarevent.mdown

@@ -13,15 +13,15 @@ A **CalendarEvent** object contains information about an event, or recurring ser
 
 ## CalendarEvent/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1.
+Standard "/get" method as described in [@!RFC8620] section 5.1.
 
 ## CalendarEvent/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2
+Standard "/changes" method as described in [@!RFC8620] section 5.2
 
 ## CalendarEvent/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3.
+Standard "/set" method as described in [@!RFC8620] section 5.3.
 
 When an event is created, updated or destroyed, the server MUST also ensure the following:
 
@@ -36,11 +36,11 @@ When an event is created, updated or destroyed, the server MUST also ensure the
 
 ## CalendarEvent/copy
 
-Standard "/copy" method as described in [@!I-D.ietf-jmap-core] section 5.4.
+Standard "/copy" method as described in [@!RFC8620] section 5.4.
 
 ## CalendarEvent/query
 
-Standard "/query" method as described in [@!I-D.ietf-jmap-core] section 5.5.
+Standard "/query" method as described in [@!RFC8620] section 5.5.
 
 ### Filtering
 
@@ -83,4 +83,4 @@ The following properties MUST be supported for sorting:
 
 ## CalendarEvent/queryChanges
 
-Standard "/queryChanges" method as described in [@!I-D.ietf-jmap-core] section 5.6.
+Standard "/queryChanges" method as described in [@!RFC8620] section 5.6.

spec/calendars/intro.mdown

@@ -1,14 +1,14 @@
 # Introduction
 
-JMAP ([@!I-D.ietf-jmap-core] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
+JMAP ([@!RFC8620] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
 
 This specification defines a data model for synchronising calendar data between a client and a server using JMAP.
 
 ## Notational conventions
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [@!RFC2119] [@!RFC8174] when, and only when, they appear in all capitals, as shown here.
 
-Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!I-D.ietf-jmap-core].
+Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!RFC8620].
 
 Object properties may also have a set of attributes defined along with the type
 signature. These have the following meanings:

spec/calendars/securityconsiderations.mdown

@@ -1,5 +1,5 @@
 # Security considerations
 
-All security considerations of JMAP ([@!I-D.ietf-jmap-core]) apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.
+All security considerations of JMAP ([@!RFC8620]) apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.
 
 TODO

spec/contacts/contact.mdown

@@ -103,15 +103,15 @@ A **File** Object has the following properties:
 
 ## Contact/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1. The *ids* argument may be `null` to fetch all at once.
+Standard "/get" method as described in [@!RFC8620] section 5.1. The *ids* argument may be `null` to fetch all at once.
 
 ## Contact/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2.
+Standard "/changes" method as described in [@!RFC8620] section 5.2.
 
 ## Contact/query
 
-Standard "/query" method as described in [@!I-D.ietf-jmap-core] section 5.5.
+Standard "/query" method as described in [@!RFC8620] section 5.5.
 
 ### Filtering
 
@@ -174,15 +174,15 @@ The following properties MUST be supported for sorting:
 
 ## Contact/queryChanges
 
-Standard "/queryChanges" method as described in [@!I-D.ietf-jmap-core] section 5.6.
+Standard "/queryChanges" method as described in [@!RFC8620] section 5.6.
 
 ## Contact/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3.
+Standard "/set" method as described in [@!RFC8620] section 5.3.
 
-To set a new avatar, the file must first be uploaded using the upload mechanism as described in [@!I-D.ietf-jmap-core] section 6.1. This will give the client a valid blobId/size/type to use. The server SHOULD reject attempts to set a file that is not a recognised image type as the avatar for a contact.
+To set a new avatar, the file must first be uploaded using the upload mechanism as described in [@!RFC8620] section 6.1. This will give the client a valid blobId/size/type to use. The server SHOULD reject attempts to set a file that is not a recognised image type as the avatar for a contact.
 
 ## Contact/copy
 
-Standard "/copy" method as described in [@!I-D.ietf-jmap-core] section 5.4.
+Standard "/copy" method as described in [@!RFC8620] section 5.4.
 

spec/contacts/contactgroup.mdown

@@ -11,12 +11,12 @@ A **ContactGroup** object represents a named set of contacts. It has the followi
 
 ## ContactGroup/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1. The *ids* argument may be `null` to fetch all at once.
+Standard "/get" method as described in [@!RFC8620] section 5.1. The *ids* argument may be `null` to fetch all at once.
 
 ## ContactGroup/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2.
+Standard "/changes" method as described in [@!RFC8620] section 5.2.
 
 ## ContactGroup/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3.
+Standard "/set" method as described in [@!RFC8620] section 5.3.

spec/contacts/intro.mdown

@@ -1,14 +1,14 @@
 # Introduction
 
-JMAP ([@!I-D.ietf-jmap-core] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
+JMAP ([@!RFC8620] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
 
 This specification defines a data model for synchronising contacts between a client and a server using JMAP.
 
 ## Notational conventions
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [@!RFC2119] [@!RFC8174] when, and only when, they appear in all capitals, as shown here.
 
-Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!I-D.ietf-jmap-core].
+Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!RFC8620].
 
 Object properties may also have a set of attributes defined along with the type
 signature. These have the following meanings:

spec/contacts/securityconsiderations.mdown

@@ -1,5 +1,5 @@
 # Security considerations
 
-All security considerations of JMAP ([@!I-D.ietf-jmap-core]) apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.
+All security considerations of JMAP ([@!RFC8620]) apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.
 
 TODO

spec/mail/ianaconsiderations.mdown

@@ -272,7 +272,7 @@ Usage Notes: JMAP only
 
 ## JMAP Error Codes registry
 
-The following sub-sections register several new error codes in the JMAP Error Codes registry, as defined in [@!I-D.ietf-jmap-core].
+The following sub-sections register several new error codes in the JMAP Error Codes registry, as defined in [@!RFC8620].
 
 ### mailboxHasChild
 

spec/mail/identity.mdown

@@ -27,15 +27,15 @@ The following JMAP methods are supported:
 
 ## Identity/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1. The *ids* argument may be `null` to fetch all at once.
+Standard "/get" method as described in [@!RFC8620] section 5.1. The *ids* argument may be `null` to fetch all at once.
 
 ## Identity/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2.
+Standard "/changes" method as described in [@!RFC8620] section 5.2.
 
 ## Identity/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3. The following extra *SetError* types are defined:
+Standard "/set" method as described in [@!RFC8620] section 5.3. The following extra *SetError* types are defined:
 
 For **create**:
 

spec/mail/intro.mdown

@@ -1,6 +1,6 @@
 # Introduction
 
-JMAP ([@!I-D.ietf-jmap-core] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
+JMAP ([@!RFC8620] – JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types.
 
 This specification defines a data model for accessing a mail store over JMAP,
 allowing you to query, read, organise and submit mail for sending.
@@ -29,7 +29,7 @@ user's inbox has been shared read-only with them.
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [@!RFC2119] [@!RFC8174] when, and only when, they appear in all capitals, as shown here.
 
-Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!I-D.ietf-jmap-core]. Data types defined in the core specification are also used in this document.
+Type signatures, examples and property descriptions in this document follow the conventions established in section 1.1 of [@!RFC8620]. Data types defined in the core specification are also used in this document.
 
 Servers MUST support all properties specified for the new data types defined in this document.
 
@@ -39,7 +39,7 @@ The same terminology is used in this document as in the core JMAP specification.
 
 ## Additions to the capabilities object
 
-The capabilities object is returned as part of the JMAP Session object; see [@!I-D.ietf-jmap-core], section 2.
+The capabilities object is returned as part of the JMAP Session object; see [@!RFC8620], section 2.
 
 This document defines three additional capability URIs.
 
@@ -105,15 +105,15 @@ The server MUST include the appropriate capability strings as keys in the *accou
 
 ## Push
 
-Servers MUST support the JMAP push mechanisms, as specified in [@!I-D.ietf-jmap-core] section 7, to receive notifications when the state changes for any of the types defined in this specification.
+Servers MUST support the JMAP push mechanisms, as specified in [@!RFC8620] section 7, to receive notifications when the state changes for any of the types defined in this specification.
 
 In addition, servers that implement the "urn:ietf:params:jmap:mail" capability MUST support pushing state changes for a type called "EmailDelivery". There are no methods to act on this type; it only exists as part of the push mechanism. The state string for this MUST change whenever a new Email is added to the store, but SHOULD NOT change upon any other change to the Email objects, for example if one is marked as read or deleted.
 
 Clients in battery constrained environments may wish to delay fetching changes initiated by the user, but fetch new messages immediately so they can notify the user. To do this, they can register for pushes for the EmailDelivery type rather than the Email type (defined in section 4).
 
 ### Example
 
-The client has registered for push notifications (see [@!I-D.ietf-jmap-core]) just for the `EmailDelivery` type. The user marks an email as read on another device, causing the state string for the `Email` type to change, however as nothing new was added to the store the `EmailDelivery` state does not change and nothing is pushed to the client. A new message arrives in the user's inbox, again causing the `Email` state to change. This time the `EmailDelivery` state also changes, and a StateChange object is pushed to the client with the new state string. The client may then resync to fetch the new message immediately.
+The client has registered for push notifications (see [@!RFC8620]) just for the `EmailDelivery` type. The user marks an email as read on another device, causing the state string for the `Email` type to change, however as nothing new was added to the store the `EmailDelivery` state does not change and nothing is pushed to the client. A new message arrives in the user's inbox, again causing the `Email` state to change. This time the `EmailDelivery` state also changes, and a StateChange object is pushed to the client with the new state string. The client may then resync to fetch the new message immediately.
 
 ## Ids
 

spec/mail/mailbox.mdown

@@ -84,11 +84,11 @@ The following JMAP methods are supported:
 
 ## Mailbox/get
 
-Standard "/get" method as described in [@!I-D.ietf-jmap-core] section 5.1. The *ids* argument may be `null` to fetch all at once.
+Standard "/get" method as described in [@!RFC8620] section 5.1. The *ids* argument may be `null` to fetch all at once.
 
 ## Mailbox/changes
 
-Standard "/changes" method as described in [@!I-D.ietf-jmap-core] section 5.2, but with one extra argument to the response:
+Standard "/changes" method as described in [@!RFC8620] section 5.2, but with one extra argument to the response:
 
 - **updatedProperties**: `String[]|null`
   If only the mailbox counts (unread/total emails/threads) have changed since the old state, this will be the list of properties that may have changed, i.e. `["totalEmails", "unreadEmails", "totalThreads", "unreadThreads"]`. If the server is unable to tell if only counts have changed, it MUST just be `null`.
@@ -97,7 +97,7 @@ Since counts frequently change but other properties are generally only changed r
 
 ## Mailbox/query
 
-Standard "/query" method as described in [@!I-D.ietf-jmap-core] section 5.5, but with the following additional request argument:
+Standard "/query" method as described in [@!RFC8620] section 5.5, but with the following additional request argument:
 
 - **sortAsTree**: `Boolean` (default: false)
   If `true`, when sorting the query results and comparing two mailboxes a and b:
@@ -136,11 +136,11 @@ The following Mailbox properties MUST be supported for sorting:
 
 ## Mailbox/queryChanges
 
-Standard "/queryChanges" method as described in [@!I-D.ietf-jmap-core] section 5.6.
+Standard "/queryChanges" method as described in [@!RFC8620] section 5.6.
 
 ## Mailbox/set
 
-Standard "/set" method as described in [@!I-D.ietf-jmap-core] section 5.3, but with the following additional request argument:
+Standard "/set" method as described in [@!RFC8620] section 5.3, but with the following additional request argument:
 
 - **onDestroyRemoveMessages**: `Boolean` (default: false)
   If `false`, any attempt to destroy a mailbox that still has messages in it will be rejected with a `mailboxHasEmail` SetError. If `true`, any messages that were in the mailbox will be removed from it, and if in no other mailboxes will be destroyed when the mailbox is destroyed.