Agenda for vCon, IETF 122, Bangkok

Chairs: Chris Wendt, Brian Rosen
Charter: https://datatracker.ietf.org/doc/charter-ietf-vcon/
Mailing list: vcon@ietf.org
2025-03-21 8:00 - 9:30 UTC, Room: Boromphimarn 3

Intro/Agenda Bashing: Chairs (5 min)

• Document Discussion addition

Draft Discussions (35 min)

Dan Petrie - The JSON format for vCon - Conversation Data Container

• https://datatracker.ietf.org/doc/draft-ietf-vcon-vcon-container/
• draft-ietf-vcon-vcon-container-02
• Dan
• Document restructuing & vCon extensions
• vCon Document Roadmap, incorporating feedback from several folks
• Can we define a vCon core, with a framework & extensions
• Split out the contact center to a separate extension
• Keep core schema in the original document
• Feedback from Orie, split out usecases to a separate document
• Rohan - consider publishing it, but put it off 'till it's done
• Rohan has a set of extensions for mimi
• Privacy Primer - extract from those requirements & use cases, maybe
  a privacy extension
• vCon Core & Extensions
• Describe requirments and I-D for extensions, with an IANA registry
• Johnathan - q-log has a good framework to consider

• issues addressed in 02 version

  • details in the slides

• medaiatypes - believe these are resolved, suggestion to get early
  review

  • application/vcon, application/vcon+gzip

• Hackathon Update

  • Testing of migration, with oss from 0.0.1 - 0.0.2
  • Separate recordings per party
  • Continued exploration of appended vCon
  • Repo: http://github.com/py-vcon/py-vcon

• Open Issues

• Separate Recordings per Party
• Multiple dialog objets - believe the oss implementation will already
  support this
• Jonathan: call out video recording, where there may be multiples per
  party, if they're silienced for a bit

• Thomas: The difference between the two options would be

  • Dan an array of recordings

• Appended vCon

  • Need to decide which direction to go
  • Deep copy is "simpler", but aplifies the size considerably
  • Defined an overlay concerpt, that is temporary

• Thomas

  • Confused the mechansim with the intent
  • We have the redacted, but could have expanded
  • Could have done parent/child relationships
  • Maybe we shouldn't have appended/redacted, rather derived from

• Dan If it's redacted, you do want to remove

• Jonathan: would both options be terrible
• Dan: redacted is different from edited
• Steve: there's a life of a vCon, where new elements are added over
  time, but at any point in time, you only want to share portions of
  the overall vcon, without having to duplicate them
• Chris: can we get some list discussion on the use cases
• vCon Version: suggestion to use a different property for the
  version. Dan, strongly against it as it will destabilize vcons in
  the wild
• Thomas: the current version isn't semantic versioning
• Orie: talk to Mike Jones about versioning. General feeling around
  versioning json documents, is you shouldn't be doing it, at all, as
  it causes havoc of json parsers. Unless you're really sure hou need
  this,
• Andy: I'm not as strong as Orie if you should need, it, but I'm not
  as strong about semantic versioning.
• Chris: is this one topic of extensions

• vcon URI scheme

  • Request of Steve to open a PR to the iana registration

• vcon+json - doesn't seem necessary

  • Andy: should goto the mediatype review team

• end to end session id - RFC7989, happy to add if others think it's
  important

  • Thomas: have seen a few places where session id was placed into
    the dialog for tracing purposes
  • Chris: is there a difference between e2e session id and session
    id
  • Dan: relates to SIP

• Still need to do

  • Dan Requests for help with ECRIT
  • Thomas: Ongoing fax project, to have a fax machine spill out a
    vcon

• Chris: are these just what's been brought up, or are these issues,
  what is the maturity level of these

  • would be good for people to review, for things like consent,
    authentication, references to STIR

Rohan Mahy - Discussions on updates for -02 (15 min)

• https://datatracker.ietf.org/doc/html/draft-mahy-vcon-mimi-messages
• Instant Messaging

• Use cases are backup, and forwarding a message to someone else

  • My old phone, back it up, reload it on a new phone
  • I'm in a chat with Dan/Chris/Orie, and need to bring Andy up to
    speed

• Changes since -01

  • see slides

• Thomas: Have you tried to implement an SMS network with this schema

• Don't see why it wouldn't work, but don't know of anyone that has
  implemented it yet

• Chris: since you're writing an extension, what's your feedback about
  the ability to write an extension, based on what's in the current
  document

  • Rohan: I was able to write the extension, I haven't yet hit an
    issue
  • Chris: do we need a format framework for extensions
  • Something for messages in the harter
  • Do we want to do one more

• Dan: thinks it's a great extension, we should adopt it, and no need
  to delay for the extension framework

• Jonathan: in addition to it being done and useful, helps get the
  extension doc right

Discussion about adoption (15 min)

• https://datatracker.ietf.org/doc/draft-james-privacy-primer-vcon/
• Spoke with the authors, and believe the opinion is still to adopt
• Dan: Definitley relevant to vCon, but wonder if it's a broader scope
  beyond vCon. Should it go through dispatch to be presented,
  reviewed,
• Maybe there's a privacy extension, but is this the right place to
  review the document.
• Thomas: in our charter, we say we have to discuss the privacy stuff.
  Believe this is the right group as it's targetd towards those using
  vcons. I think it's a really good idea to have other groups get it
  right, but think it
• Steve: found it's really helpful for how to use and understand the
  very sensitive PII information, and how to use it.
• Murray: you can ask SecDir about the document. You have resources
  for how to get ahead of it
• Dan: are we talking about publishing it as an RFC.
• Chris: if we're adopting it, yes, we're heading that direction
• Thomas: Yes, this was meant to be informational, for those reading
  the protocol, how to use it. I would put it on the informational
  track.
• Andy: Just reading it, it seems information. If it's useful for
  people outside of this group, it should be published it as an RFC.
• Lisa: should go at the same time as the other documents
• Murray: it's 21 pages, can you shrink it and put it in the main
  document.
• Chris: are we still good with a call for adoption? Room says yes.~

Wrap up: Chairs (5 min)

• Thomas: Similar proposal to Dan's.

• Two problems to be solved

  • Thinking about the reader, and how they'll traverse the
    documents, and how we can make them better: Informational
  • Standards Track Docs

• vCons are dynamic, for instance consent can be granted or revoked

• DataTypes
• Privacy Considerations
• Dan: proposing combining some of those documents. For instance the
  architecture doesn't seem to be needed, as it's just a json schema.
  Grandeous to call it architecture. I don't think there's a lot of
  usecase documentation, and it's a pretty small draft. And, the
  extensions, and the use cases
• Chris: we've talked about extensions in the WG, we've talked about
  privacy, maybe architeture and framework.
• Thomas: Maybe can make it very practical, such as SCITT and vCons,
  and think that's a type of a document we need. The architecture
  speaks to how we use the various components, such as extensions
• Orie: looking at the charter, you have a standards track section,
  and an informational section. I like the idea of a document for json
  schema. The last one talks about media types. Those seems to be the
  scope of the standards track. The others seems to be a bunch of use
  cases. The security document, might be part of the security section.
  The charter doesn't seem to imply these additional documents. You
  have a litmted set of documents, and should get to them.
• Chris: is the group on the same page about what we should be working
  on.
• Orie: the word extensions doesn't even show up once. The core json
  schema, could come with an extension section. The charter doesn't
  talk about extensions.
• Dan: what is in the charter, messaging ECRIT and contact center are
  called out as use cases to be supported.
• Orie: There are use cases, but they're informational.