Session Initiation Protocol (SIP) Call Control - Transfer
draft-ietf-sipping-cc-transfer-12

[Ballot discuss]
Two things I want to talk about for the AIB in section 8 - they may be fine in the draft but I'm not sure.

1) It seems to me that having the multipart/signed inside the multipart/mixed is wrong because there are no other bodies in the mixed. It should just be a multipart/signed

2) I seem to recall checking the S/MIME signature long ago but I can't get it to parse any more. I might be extracting the binary representation in the wrong way. How are you doing this and I will try to duplicate.

[Ballot discuss]
Two things I want to talk about for the AIB in section 8 - they may be fine in the draft but I'm not sure.

1) It seems to me that having the multipart/signed inside the multipart/mixed is wrong because there are no other bodies in the mixed. It should just be a multipart/signed

2) I seem to recall checking the S/MIME signature long ago but I can't get it to parse any more. I might be extracting the binary representation in the wrong way. How are you doing this and I will try to duplicate.

Just testing tool.

Thanks, Cullen

[Ballot comment]
I support Cullen's discuss about multipart wrapping.  While a single-part
multipart/mixed is legal MIME and in theory equivalent to moving the
inner part up a level; in practice the extra wrapper tends to confound
processing agents and UIs.

Because both cases are MIME compliant, this falls under the "be liberal
in what you accept, conservative in what you send" principle.  So it's
bad practice to misbehave when receiving a single-part multipart/mixed,
but it's also bad practice to send it in the first place.  While a "bad
sending practice" example may be useful in specs to help receivers get
more robust, it needs to be identified as a bad practice.

[Ballot discuss]
Two things I want to talk about for the AIB in section 8 - they may be fine in the draft but I'm not sure.

1) It seems to me that having the multipart/signed inside the multipart/mixed is wrong because there are no other bodies in the mixed. It should just be a multipart/signed

2) I seem to recall checking the S/MIME signature long ago but I can't get it to parse any more. I might be extracting the binary representation in the wrong way. How are you doing this and I will try to duplicate.

Thanks, Cullen

[Ballot comment]
Typo at the end of section 11.1:
  >
  > If the gateway supports more than one truck group,
  >
  s/truck/trunk/

[Ballot discuss]
Brian Carpenter provided a Gen-ART Review on 6-Oct-2008, and I have
  not seen a response.  Please respond.  I'm especially concerned about
  this comment:
  > ... I found it hard in sections 5 through 11 to figure out what was
  > normative and what was illustrative. Does that "can be" imply that
  > there may be another method? I found no MUSTs, two SHOULDs, one
  > NOT RECOMMENDED, and one MAY. There are some lower case "shoulds"
  > - are they normative?  Are the call flows normative? If so, I think
  > this should be stated explicitly in section 5.

[Ballot comment]
Section 5
s/he Transferee had initiated/the Transferee had initiated/

Section 7.2
s/different that in current/different than in current/

Section 7.5, Figure 9
I believe the Invite associated with dialog4 should be dialog3

Section 7.5, Figure 10
I was confused by the messages associated with dialogs 3 and 4.
I thought the final BYE/200 OK should be associated with dialog4
rather than dialog3.  It looks like dialog3 never terminates; is
a message missing?

Section 7.6
s/to a race conditions/to race conditions/
s/In this, case the call flow/In this case, the call flow/

Section 9, Figure 16
The figure omits dialog numbers.

State Changes to Last Call Requested from AD Evaluation's state and the current
  server state, the server SHOULD generate an update to take the client
  to an intermediate state, from which the client can continue to call
  _Foo/changes_ until it is fully up to date.  If it is unable to
  calculate an intermediate state, it MUST return a
  "cannotCalculateChanges" error response instead.

Jenkins & Newman        Expires March 14, 2019                [Page 26]
Internet-Draft                    JMAP                    September 2018

  When generating intermediate states, the server may choose how to
  divide up the changes.  For many types it will provide a better user
  experience to return the more recent changes first, as this is more
  likely to be what the user is most interested in.  The client can
  then continue to page in the older changes while the user is viewing
  the newer data.  For example, suppose a server went through the
  following states:

                          A -> B -> C -> D -> E

  And a client asks for changes from state "B".  The server might first
  get the ids of records created, updated or destroyed between states D
  and E, returning them with:

                          state: "B-D-E"
                          hasMoreChanges: true

  The client will then ask for the change from state "B-D-E", and the
  server can return the changes between states C and D, returning:

                          state: "B-C-E"
                          hasMoreChanges: true

  Finally the client will request the changes from "B-C-E" and the
  server can return the changes between states B and C, returning:

                          state: "E"
                          hasMoreChanges: false

  Should the state on the server be modified in the middle of all this
  (to "F"), the server still does the same but now when the update to
  state "E" is returned, it would indicate that it still has more
  changes for the client to fetch.

  Where multiple changes to a record are split across different
  intermediate states, the server MUST NOT return a record as created
  in a later response than one which gives it as updated or destroyed,
  and MUST NOT return a record as destroyed before a response that
  gives it as created or updated.  The server may have to coalesce
  multiple changes to a record to satisfy this requirement.

  The following additional errors may be returned instead of the _Foo/
  changes_ response:

  "cannotCalculateChanges": The server cannot calculate the changes
  from the state string given by the client.  Usually due to the
  client's state being too old, or the server being unable to produce

Jenkins & Newman        Expires March 14, 2019                [Page 27]
Internet-Draft                    JMAP                    September 2018

  an update to an intermediate state when there are too many updates.
  The client MUST invalidate its Foo cache.

  Maintaining state to allow calculation of _Foo/changes_ can be
  expensive for the server, but always returning
  _cannotCalculateChanges_ severely increases network traffic and
  resource usage for the client.  To allow efficient sync, servers
  SHOULD be able to calculate changes from any state string that was
  given to a client within the last 30 days (but of course may support
  calculating updates from states older than this).

5.3.  /set

  Modifying the state of Foo objects on the server is done via the
  _Foo/set_ method.  This encompasses creating, updating and destroying
  Foo records.  This allows the server to sort out ordering and
  dependencies that may exist if doing multiple operations at once (for
  example to ensure there is always a minimum number of a certain
  record type).

  The _Foo/set_ method takes the following arguments:

  o  *accountId*: "String" The id of the account to use.

  o  *ifInState*: "String|null" This is a state string as returned by
      the _Foo/get_ method.  If supplied, the string must match the
      current state, otherwise the method will be aborted and a
      "stateMismatch" error returned.  If "null", any changes will be
      applied to the current state.

  o  *create*: "String[Foo]|null" A map of _creation id_ (an arbitrary
      string set by the client) to Foo objects, or "null" if no objects
      are to be created.  The Foo object type definition MAY define
      default values for properties.  Any such property MAY be omitted
      by the client.  The client MUST omit any properties that may only
      be set by the server (for example, the _id_ property on most
      object types).

  o  *update*: "String[PatchObject]|null" A map of id to a Patch object
      to apply to the current Foo object with that id, or "null" if no
      objects are to be updated.  A _PatchObject_ is of type
      "String[*]", and represents an unordered set of patches.  The keys
      are a path in [RFC6901] JSON pointer format, with an implicit
      leading "/" (i.e. prefix each key with "/" before applying the
      JSON pointer evaluation algorithm).  All paths MUST also conform
      to the following restrictions; if there is any violation, the
      update MUST be rejected with an "invalidPatch" error:

Jenkins & Newman        Expires March 14, 2019                [Page 28]
Internet-Draft                    JMAP                    September 2018

      *  The pointer MUST NOT reference inside an array (i.e. you MUST
        NOT insert/delete from an array; the array MUST be replaced in
        its entirety instead).

      *  All parts prior to the last (i.e. the value after the final
        slash) MUST already exist on the object being patched.

      *  There MUST NOT be two patches in the PatchObject where the
        pointer of one is the prefix of the pointer of the other, e.g.
        "alerts/1/offset" and "alerts".

      The value associated with each pointer determines how to apply
      that patch:

      *  If "null", set to the default value if specified for this
        property, otherwise remove the property from the patched
        object.  If the key is not present in the parent, this a no-op.

      *  Anything else: The value to set for this property (this may be
        a replacement or addition to the object being patched).

      Any server-set properties MAY be included in the patch if their
      value is identical to the current server value (before applying
      the patches to the object).  Otherwise, the update MUST be
      rejected with an _invalidProperties_ SetError.  This patch
      definition is designed such that an entire Foo object is also a
      valid PatchObject.  The client MAY choose to optimise network
      usage by just sending the diff, or MAY just send the whole object;
      the server processes it the same either way.

  o  *destroy*: "String[]|null" A list of ids for Foo objects to
      permanently delete, or "null" if no objects are to be destroyed.

  Each creation, modification or destruction of an object is considered
  an atomic unit.  It is permissible for the server to commit changes
  to some objects but not others, however it is not permissible to only
  commit part of an update to a single record (e.g. update a _name_
  property but not a _count_ property, if both are supplied in the
  update object).

  The final state MUST be valid after the Foo/set is finished, however
  the server may have to transition through invalid intermediate states
  (not exposed to the client) while processing the individual
  create/update/destroy requests.  For example, suppose there is a
  "name" property that must be unique.  A single method call could
  rename an object A => B, and simultaneously rename another object B
  => A.  If the final state is valid, this is allowed.  Otherwise, each
  creation, modification or destruction of an object should be

Jenkins & Newman        Expires March 14, 2019                [Page 29]
Internet-Draft                    JMAP                    September 2018

  processed sequentially and accepted/rejected based on the current
  server state.

  If a create, update or destroy is rejected, the appropriate error
  MUST be added to the notCreated/notUpdated/notDestroyed property of
  the response and the server MUST continue to the next create/update/
  destroy.  It does not terminate the method.

  If an id given cannot be found, the update or destroy MUST be
  rejected with a "notFound" set error.

  The server MAY skip an update (rejecting it with a "willDestroy"
  SetError) if that object is destroyed in the same /set request.

  Some record objects may hold references to others (foreign keys).
  When records are created or modified, they may reference other
  records being created _in the same API request_ by using the creation
  id prefixed with a "#".  The order of the method calls in the request
  by the client MUST be such that the record being referenced is
  created in the same or an earlier call.  The server thus never has to
  look ahead.  Instead, while processing a request (a series of method
  calls), the server MUST keep a simple map for the duration of the
  request of creation id to record id for each newly created record, so
  it can substitute in the correct value if necessary in later method
  calls.

  Creation ids are not scoped by type but are a single map for all
  types.  A client SHOULD NOT reuse a creation id anywhere in the same
  API request.  If a creation id is reused, the server MUST map the
  creation id to the most recently created item with that id.  To allow
  easy proxying of API requests, an initial set of creation id to real
  id values may be passed with a request (see The Request object
  specification above).

  The response has the following arguments:

  o  *accountId*: "String" The id of the account used for the call.

  o  *oldState*: "String|null" The state string that would have been
      returned by _Foo/get_ before making the requested changes, or
      "null" if the server doesn't know what the previous state string
      was.

  o  *newState*: "String" The state string that will now be returned by
      _Foo/get_.

  o  *created*: "String[Foo]|null" A map of the creation id to an
      object containing any properties of the created Foo object that

Jenkins & Newman        Expires March 14, 2019                [Page 30]
Internet-Draft                    JMAP                    September 2018

      were not sent by the client.  This includes all server-set
      properties (such as the _id_ in most object types) and any
      properties that were omitted by the client and so set to a default
      by the server.  This argument is "null" if no Foo objects were
      successfully created.

  o  *updated*: "String[Foo|null]|null" The _keys_ in this map are the
      ids of all Foos that were successfully updated, or "null" if none
      successful.  The _value_ for each id is a Foo object containing
      any property that changed in a way _not_ explicitly requested by
      the _PatchObject_ sent to the server, or "null" if none.  This
      lets the client know of any changes to server-set or computed
      properties.

  o  *destroyed*: "String[]|null" A list of Foo ids for records that
      were successfully destroyed, or "null" if none successful.

  o  *notCreated*: "String[SetError]|null" A map of creation id to a
      SetError object for each record that failed to be created, or
      "null" if all successful.

  o  *notUpdated*: "String[SetError]|null" A map of Foo id to a
      SetError object for each record that failed to be updated, or
      "null" if all successful.

  o  *notDestroyed*: "String[SetError]|null" A map of Foo id to a
      SetError object for each record that failed to be destroyed, or
      "null" if all successful.

  A *SetError* object has the following properties:

  o  *type*: "String" The type of error.

  o  *description*: "String|null& by Jon Peterson

State Changes to AD Evaluation from Publication Requested by Jon Petersonquot;, with a positive
  integer value representing a length of time in seconds, e.g.
  "ping=300".  If set, the server MUST send an event called *ping*
  whenever this time elapses since the previous event was sent.  This
  MUST NOT set a new event id.

  The server MAY modify the interval given as a query parameter to be
  subject to a minimum and/or maximum value.  For interoperability,
  servers MUST NOT have a minimum allowed value higher than 30 or a
  maximum allowed value less than 300.

  The data for the ping event MUST be a JSON object containing an
  _interval_ property, the value (type "PositiveInt") being the
  interval in seconds the server is using to send pings (this may be
  different to the requested value if the server clamped it to be
  within a min/max value).

Jenkins & Newman        Expires March 14, 2019                [Page 57]
Internet-Draft                    JMAP                    September 2018

  Clients can monitor for the _ping_ event to help determine when the
  closeafter mode may be required.

  Refer to the JMAP Session resource section of this spec for details
  on how to get the URL for the event-source resource.  Requests to the
  resource MUST be authenticated.

  A client MAY hold open multiple connections to the event-source
  resource, although it SHOULD try to use a single connection for
  efficiency.

8.  Security considerations

8.1.  Transport confidentiality

  All HTTP requests MUST use [RFC5246] TLS (https) transport to ensure
  the confidentiality of data sent and received via JMAP.  Clients MUST
  validate TLS certificate chains to protect against man-in-the-middle
  attacks.

8.2.  Authentication scheme

  A number of HTTP authentication schemes have been standardised
  (<https://www.iana.org/assignments/http-authschemes/http-
  authschemes.xhtml>).  Servers should take care to assess the security
  characteristics of different schemes in relation to their needs when
  deciding what to implement.

  If offering the Basic authentication scheme, services are strongly
  recommended to not allow a user's regular password but require
  generation of a unique "app password" via some external mechanism for
  each client they wish to connect.  This allows connections from
  different devices to be differentiated by the server, and access to
  be individually revoked.

8.3.  Service autodiscovery

  Unless secured by something like DNSSEC, autodiscovery of server
  details is vulnerable to a DNS poisoning attack leading to the client
  talking to an attacker's server instead of the real JMAP server.  The
  attacker may then man-in-the-middle requests and depending on the
  authentication scheme, steal credentials to generate its own
  requests.

  Clients that do not support SRV lookups are likely to try just using
  the "/.well-known/jmap" path directly against the domain of the
  username over HTTPS.  Servers SHOULD ensure this path resolves or
  redirects to the correct JMAP Session resource to allow this to work.

Jenkins & Newman        Expires March 14, 2019                [Page 58]
Internet-Draft                    JMAP                    September 2018

  If this is not feasible, servers MUST ensure this path cannot be
  controlled by an attacker, as again it may be used to steal
  credentials.

8.4.  JSON parsing

  The security considerations of [RFC7159] apply to the use of JSON as
  the data interchange format.

8.5.  Denial of service

  A small request may result in a very large response, and require
  considerable work on the server if resource limits are not enforced.
  JMAP provides mechanisms for advertising and enforcing a wide variety
  of limits for mitigating this threat, including limits on number of
  objects fetched in a single method call, number of methods in a
  single request, number of concurrent requests, etc.

  JMAP servers MUST implement sensible limits to mitigate against
  resource exhaustion attacks.

8.6.  Push encryption

  When data changes, a small object is pushed with the new state
  strings for the types that have changed.  While the data here is
  minimal, a passive man-in-the-middle attacker may be able to gain
  useful information.  To ensure confidentiality, if the push is sent
  via a third party outside of the control of the client and JMAP
  server the client MUST specify encryption keys when establishing the
  PushSubscription.

  The privacy and security considerations of [RFC8030] and [RFC8291]
  also all apply to the use of the PushSubscription mechanism.

9.  IANA considerations

9.1.  Assignment of jmap service name

  IANA will assign the 'jmap' service name in the 'Service Name and
  Transport Protocol Port Number Registry' [RFC6335].

  Service Name: jmap

  Transport Protocol(s): tcp

  Assignee: IESG

  Contact: IETF Chair

Jenkins & Newman        Expires March 14, 2019                [Page 59]
Internet-Draft                    JMAP                    September 2018

  Description: JSON Meta Application Protocol

  Reference: this document

  Assignment Notes: this service name was previously assigned under the
  name _JSON Mail Access Protocol_. This will be de-assigned and re-
  assigned with the approval of the previous assignee.

9.2.  Registration of well-known URI suffix for JMAP

  IANA will register the following well-known URI suffix for JMAP as
  described in [RFC5785]:

  URI Suffix: jmap

  Change Controller: IETF

  Specification Document: this document, section 2.2.

9.3.  Registration of the jmap URN sub-namespace

  IANA will register the following URN sub-namespace in the "IETF URN
  Sub-namespace for Registered Protocol Parameter Identifiers" registry
  as described in [RFC3553].

  Registered Parameter Identifier: jmap

  Reference: this document, next section

  IANA Registry Reference: {insert IANA registry URL for registry in
  next section, upon approval}

9.4.  Creation of "JMAP Capabilities" registry

  IANA will create a registry for JMAP capabilities as described in
  section 2.  JMAP capabilities are advertised in the _capabilities_
  property of the _JMAP Session_ resource.  They are used to extend the
  functionality of a JMAP server.  A capability is referenced by a URI.
  The JMAP capability URI can be a URN starting with
  "urn:ietf:params:jmap:" plus a unique suffix which is the index value
  in the jmap URN sub-namespace.  Registration of a JMAP capability
  with another form of URI has no impact on the jmap URN sub-namespace.

  This registry follows the expert review process unless the "intended
  use" field is _common_ or _placeholder_ in which case registration
  follows the specification required process.

Jenkins & Newman        Expires March 14, 2019                [Page 60]
Internet-Draft                    JMAP                    September 2018

  A JMAP capability registration can have an intended use of _common_,
  _placeholder_, _limited_, or _obsolete_. IANA will list common use
  registrations prominently and separately from those with other
  intended use values.

  The JMAP capability registration procedure is not a formal standards
  process, but rather an administrative procedure intended to allow
  community comment and sanity checking without excessive time delay.

  A _placeholder_ registration reserves part of the jmap urn namespace
  for another purpose but is typically not included in the
  _capabilities_ property of the _JMAP Session_ resource.

9.4.1.  Preliminary community review

  Notice of a potential JMAP common use registration SHOULD be sent to
  the jmap@ietf.org mailing list for review.  This mailing list is
  appropriate to solicit community feedback on a proposed JMAP
  capability.  Registrations that are not intended for common use MAY
  be sent to the list for review as well; doing so is entirely
  OPTIONAL, but is encouraged.

  The intent of the public posting to this list is to solicit comments
  and feedback on the choice of capability name, the unambiguity of the
  specification document, and a review of any interoperability or
  security considerations.  The submitter may submit a revised
  registration proposal or abandon the registration completely and at
  any time.

9.4.2.  Submit request to IANA

  Registration requests can be sent to iana@iana.org.

9.4.3.  Designated expert review

  For a limited use registration, the designated expert's (DE) primary
  concern is preventing name collisions and encouraging the submitter
  to document security and privacy considerations; a published
  specification is not required.  For a common use registration, the DE
  is expected to confirm that suitable documentation as described in
  [RFC8126], Section 4.6, is available.  The DE should also verify the
  capability does not conflict with work that is active or already
  published within the IETF.

  Before a period of 30 days has passed, the DE will either approve or
  deny the registration request and publish a notice of the decision to
  the JMAP WG mailing list or its successor, as well as informing IANA.
  A denial notice must be justified by an explanation, and in the cases

PROTO Write-up

> 1.a) Have the chairs personally reviewed this version of the Internet
> Draft (ID), and in particular, do they believe this ID is ready
> to forward to the IESG for publication?
>
>The SIPPING WG chairs have reviewed the document and believe it is
>ready for publication. Gonzalo Camarillo is its PROTO shepherd.
>
> 1.b) Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the
> depth or breadth of the reviews that have been performed?
>
>The draft has been thoroughly reviewed by a number of SIPPING members.
>
> 1.c) Do you have concerns that the document needs more review from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, etc.)?
>
>We do not have any particular concern in that respect.
>
> 1.d) Do you have any specific concerns/issues with this document that
> you believe the ADs and/or IESG should be aware of? For
> example, perhaps you are uncomfortable with certain parts of the
> document, or have concerns whether there really is a need for
> it. In any event, if your issues have been discussed in the WG
> and the WG has indicated it that it still wishes to advance the
> document, detail those concerns in the write-up.
>
>We feel comfortable with the document.
>
> 1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?
>
>There is strong consensus within the WG that call transfer is a very
>important service and that this is the best way to implement such a service.
>
> 1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email to the Responsible Area Director.
>
>Nobody has done anything to stop this document.
>
> 1.g) Have the chairs verified that the document adheres to all of the
> ID nits? (see http://www.ietf.org/ID-Checklist.html).
>
>Yes, it does.
>
> 1.h) Is the document split into normative and informative references?
> Are there normative references to IDs, where the IDs are not
> also ready for advancement or are otherwise in an unclear state?
> (note here that the RFC editor will not publish an RFC with
> normative references to IDs, it will delay publication until all
> such IDs are also ready for publication as RFCs.)
>
>All the normative references are RFCs. xxx GRUU is still a draft.
>
> 1.i) For Standards Track and BCP documents, the IESG approval
> announcement includes a write-up section with the following
> sections:
>
> * Technical Summary
>
> This document describes providing Call Transfer capabilities in the
> Session Initiation Protocol (SIP). SIP extensions such as REFER and
> Replaces are used to provide a number of transfer services including
> blind transfer, consultative transfer, and attended transfer. This
> work is part of the SIP multiparty call control framework.
>
> * Working Group Summary
>
>This draft progressed slowly because it uses mechanisms defined in other
>documents. The document had to wait until those mechanisms were ready.
>Otherwise, folks in the WG agreed with the direction of the draft from
>the beginning.
>
> * Protocol Quality
>
>Jon Peterson is the Responsible Area Director. The WG chair shepherd
>for the document is Gonzalo Camarillo.
>