text: See also: IRC log
   discussions Boston ]
  [ hta reads slide ]
  hta: any comments/complaints?
  [ None ]
  cullen: thanks guys for doing this
  [ MediaStream Cropping ]
  justin: this is a quick set of
  slides i put together
  ... for how a camera could stream could be provided in an aspect ratio not equal to native
  [ Problem statement ]
  <dom> Justin's slides on aspect ratio> CIF on wikipedia> HTML5 spec says: "In the absence of style rules to the contrary, video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match
  
  -> object-fit in CSS Image Values and Replaced Content Module Level 3
  -> object-fit in caniuse]
  <trackbot> Created ACTION-84 - Describe the constraint for aspect ratio for potential inclusion in the document [on Justin Uberti - due 2013-02-14].
  <timeless> scribe: timeless
  hta: there are cases where we
  need to provide more information than just the error name
  ... e.g. when there is an sdp error
  ... we want the line of where the SDP arose
  <inserted> ScribeNick: timeless
  hta: could people help me refresh my memory?
  burn: we were trying to finalize
  the principles
  ... but we decided we needed to look at specific
  ... and Adam Roach said we needed to hear from implementers
  ... as they implement
  ... instead of "ooh, maybe it will do this, maybe it will do that"
  ekr: what errors we're
  seeing
  ... what you need to return
  ... how often, and when
  ... justin and i are debating Error1, or Error2 and Error3
  ... i mostly see malformed SDP
  ... a browser screwed it up, or someone mangled it
  ... a parser of why i didn't like it and what it was
  ... Adam Roach pointed out the same need for ICE
  ... when i look at existing ICE information
  ... that would be a long way toward knowing what's going on
  ... a way to detail every check
  ... would be useful
  ... very confusing errors
  ... the only thing in the docs at all is detailed ICE info
  justin: for Chrome 25, we'll have
  which line of SDP it choked on
  ... SDP people complain about Dom11 for not having crypto lines
  ... we should see if that's useful
  ... we also created chrome:ice-debugging (not for JS)
  ... to allow people to debug apps w/o exposing js apis to apps
  ... we'll have more debugging tools
  ... before we invent too many more things
  ekr: most of these errors are
  programming errors
  ... i think it's a great idea to have inspectors that are only accessible to programmer
  <dom> [The WebSockets API is very careful in not exposing too many details about errors: ; not sure if there are similar risks in our case]
  ekr: you test when you write
  code
  ... you don't know why
  ... once you get it working, it works
  ... ICE check failed on component 1 to the user
  ... is unlikely to help the user
  fluffy: we're putting your email
  address in our errors
  ... i don't think we've reviewed the doc for errors that can come up
  ... we're seeing implementations
  ... a port of Firefox that also does 264
  ... not being able to report up mismatches
  ... problems that you don't see since you only do one codec
  derf: how we report errors is
  good
  ... we need to define what happens when there's an error
  ... you might parse SDP, it might be valid, but not apply to session state
  ... mismatched m=lines between offer and answer
  ... i don't care about behavior, but it needs to be consistent
  ... we could Tear down the entire call
  ... we could not access the entire SDP
  ... or browser crashes
  ... but it shouldn't be inconsistent between browsers
  dom: WebSockets API is
  careful
  ... about avoiding exposing details
  ekr: SDP exposes the entire Network Topology
  <dom> [so should we drop SDP? >:]
  ekr: hta's proposal of
  statistics
  ... could be useful
  ... or if i'm showing my video instead of remote
  ... if there's no RTP coming in
  ... re derf's proposal
  ... there's going to be a whole class of things
  ... passing bogus SDP
  ... sometimes that's a parse error
  ... sometimes that's an application error
  ... standards should encourage right behavior
  ... but if you get halfway through applying an SDP
  ... i can't roll-back
  ... it might be better for me to close
  juberti: someone had a action to
  describe how rollback should happen
  ... two sets of errors
  ... @SDP layer
  ... either not eat
  ... or tear down
  ... or @SRTP
  ... and we could blow up in Security layer
  ... we can make best practices
  hta: implementer feedback
  ... some parse errors
  ... are easy, some are harder to pin down
  ... the missing crypto line is hard
  ... which line is the one to report it for?
  ... it would be nice to have some descriptive text
  ... not for applications
  ... but useful for debuggers
  <dom> [oh boy, are we now describing an SDP parser API?]
  hta: or maybe useful advice
  ekr: missing crypto line v.
  missing fingerprint
  ... having looked at jingle
  ... it wouldn't be at parse time
  ... it'd be later
  ... you need a textual report
  ... "i'm sad for reason: ..."
  ... parsers print to logging but don't propagate
  juberti: that landed last
  night
  ... in Canary
  stefanh: no big need for adding
  errors
  ... but more on what happens when you encounter an error
  hta: this is part of procedure
  description for setLocalDescription/...
  ... we left off precise language
  ... on the idea of getting the general principles before we write precise language
  ... i think it's the time to write precise language
  [ Coffee Break for 15 minutes ]
  jesup: W3 flavor of data channel
  discussion
  ... i hope less controversial than the IETF flavor
  ... maybe we'll make a decision
  [ DataChannel JS API ]
  jesup: feedback from Mozilla Devs
  working on those apis
  ... has been generally positive
  ... it's worked the way they've expected
  ... primary unresolved area
  ... is how to create data channel and how it interacts w/ createOffer/createAnswer
  [ Changes to API ]
  jesup: IETF 85 ... protocol to add data channels to agree on interop
  martin__: the web socket idea of a sub protocol?
  jesup: i guess so
  ... an IANA registered string
  ... if you do this, you agree you're exchanging in some form
  ... since we're mirroring WebSocket
  ... this is that thing from WebSocket
  adambe: latest version of WebSocket lets you say you accept multiple protocols?
  jesup: but you can only use one once it's in flight
  <dom> WebSocket Subprotocols registry
  jesup: our way to create data channel is different from WebSocket
  martin__: no need to
  negotiate
  ... it's with itself
  jesup: you would need a way to signal back agreement, complexity for no reason
  [ Proposal ]
  jesup: like yesterday, but w/o
  SDP
  ... all the JS layer
  ... no DataChannel unless you call pc.createDataChannel()
  ... you can call it any number of times before createOffer/createAnswer
  ... if called after initial createOffer, it triggers a negotiationneeded
  hta: createOffer or setLocalDescription?
  jesup: before SDP or after SDP is
  the distinction
  ... relative ICE things
  hta: what if they createOffer throw it away and call createOffer again?
  jesup: maybe `initial` is wrong
  hta: one solution is first call triggers negotiationneeded
  jesup: createStream throw away
  stream, stream is still there
  ... same for data channels
  martin__: seems like there's some need for ...
  derf: we had an AI for when negotiationneeded fires
  martin__: and when other things fire after
  [ Problems ]
  jesup: unless you sniff SDP, you won't know if there was a data channel
  <martin__> the question is a) when onnegotiationneeded fires and b) when it clears such that it could fire again
  jesup: we can't add an m=line in
  an answer
  ... if you want it, you'd need a second round of offer-answer
  [ Example ]
  <derf> martin__, I suspect the answer to b) is that it can always fire again.
  [ Decisions! (Please!) ]
  jesup: use createDataChannel to
  trigger m=application line
  ... if needed, createDataChannel will call negotiationneeded
  martin__: need to be >0 open
  channels to include m=application
  ... because you could create a data channel, close it, and then createOffer
  hta: i'm fine w/ this
  ... is that what you want?
  jesup: basically
  XXX
  paul: namespace for sub
  protocols?
  ... subordinate to webrtc channel namespace?
  ... should be same namespace as websocket subprotocols?
  ... i don't know that
  <martin__> ACTION jesup to if we replace onnegotiationneeded conditions to the same as those we have for addStream()
  <trackbot> Error finding 'jesup'. You can review and register nicknames at <>.
  jesup: i think it's an IANA register
  paul: just want a procedure
  <martin__> ACTION Randell to make onnegotiationneeded conditions the same as those we have for addStream()
  <trackbot> Error finding 'Randell'. You can review and register nicknames at <>.
  paul: to define these
  TedHardie: it's a first come
  first server registry
  ... set up by WebSocket folks
  paul: single level name
  hta: you can define protocols for
  data channel
  ... that don't work well w/ web sockets
  ... that might be an argument for different registry
  jesup: not an argument for different registry, just don't use w/ websocket
  TedHardie: for this room, push to IETF side
  jesup: i agree
  ... what `protocol` means shall be defined by IETF
  <martin__> OK, randell isn't a registered user
  Dan_Druta: protocol isn't limited to registry, right?
  jesup: if it wishes to ignore the
  registry, nothing can force it
  ... I yield the remainder of my time
  stefanh: we made a decision to go w/ this w/ hta's amendment
  <dom> ACTION: stefanh to get Randell to make onnegotiationneeded conditions the same as those we have for addStream( [recorded in]
  <trackbot> Created ACTION-85 - Get Randell to make onnegotiationneeded conditions the same as those we have for addStream( [on Stefan Håkansson - due 2013-02-14].
  [ Stats ]
  [ hta defines Microphones `chair at desk`, `speaker at wireless`, `individual at center mic` ]
  <scribe> [ New API ]
  hta: changing datatype of what
  comes back on stats report
  ... to be an object that's able to tell you the identifiers
  ... and able to get those objects
  ... each object has type and id
  ... and set of names, and a getter to get value for name
  juberti: like a Dictionary?
  <scribe> [ New Objects ]
  hta: exactly
  ... Dictionaries are a name value mapping
  ... I decided this is a fine way of putting stuff into documentation
  ... that can be checked with a WebIDL parser
  ... sequence returned order is somewhat curious
  ... depends on alphabetical names
  ... and based on hierarchy
  ... things defined in derived dictionary are added to the sequence (sorted) after the original dictionary's list
  ... this is a pain in the posterior
  ... i looked into the state of a Dictionary
  ... and how to return one from a function
  ... the answer i got is that `it's doable, w/ 3 experts in DOM state manipulation`
  ... so i propose no dictionaries
  ... [as from the previous slide ]
  [ Principles of object definition ]
  hta: use Dictionary as
  documentation method
  ... pointers are done via ID
  ... Keep it simple (and well defined)
  martin__: i'm unsympathetic to the hard to implement
  hta: did you implement something that fully implements dictionary
  martin__: one thing i didn't deal
  w/ was extra params
  ... the idea that you'd have trouble passing objects to js as hard to do...
  ... we've discussed this at length
  ... the things we're getting are key-value-pairs w/ primitives and maybe arrays
  ... but you're forcing them to use unfamiliar constructs
  adambe: JS has a way to deal w/
  KeyValue pairs
  ... couldn't we say we're returning a JS object w/ these values
  ... and not promise order
  ... that gives us enumeration and lookup from JS
  hta: one vote for
  Dictionary
  ... and one comment for Object
  fluffy: in favor of making this work
  <dom> [I think you can use [NoInterfaceObject] interface to describe regular JavaScript objects]
  fluffy: keen to restrict
  semantics to that of Dictionary
  ... if function calls get mapped to thing, this would be a disaster
  ... nearly every language has something like Dictionary
  ... I want Dictionary semantics, ... ASN.1 - i don't care
  ekr: is there an argument against
  these being properties
  ... that isn't rooted in implementation details
  ... why isn't names() and getValue() just properties of the object
  ... one is that it's Lousy for JS user
  ... and one that it's inconvenient for the C++ WebKit dev
  ... is it just PITA for WebKit?
  ... i'd have expected that a param was property index (.keys)
  ... and reference by .<> or [<>]
  fluffy: you expect Dictionary
  ekr: what's the merits of this other than implementation?
  juberti: if it was []/. instead of getValue()
  dom: i understand Dictionary is a
  pain
  ... but why not Interface
  ... this is similar to GeoLoc in a way
  ... they use [NoInterfaceObject]
  ... we shouldn't define our own way of declaring our own local data
  ... WebIDL w/ interfaces provides that
  martin__: use partial interfaces
  hta: partial interfaces w/o source
  juberti: why objects
  ... couldn't we make them more like regular dictionaries?
  hta: if `void (RTCStatsReport
  statsReport)` with a map
  ... Dictionary provides some guarantees and constraints i don't want
  martin__: it doesn't need to be a
  Dictionary
  ... it could be [] or .
  ... you can do this in JS in browsers w/ handlers
  ... i don't see a problem w/ implementation
  ... if you aren't backing directly w/ C++
  ... we need a map
  adambe: `statsReport`
  ... report is a complete thing
  ... and you have subreports
  ... you want two levels
  ... you could guarantee a timestamp, type, id
  ... why are those on a different level?
  martin__: individual stats object could be created at different times
  adambe: move timetamp/id into
  getValue?
  ... i'm disregarding the top object
  [ RTCStatsReport ]
  adambe: i don't see why we need a stats.type v. stats.getValue(x).
  hta: how do you specify that in WebIDL
  martin__: i'd rather show example code for exact number of packets
  dom: I think in WebIDL, your
  additional data structure inherits from a core interface
  ... Object is a Map
  fluffy: don't drive from
  WebIDL
  ... figure out from how you want to use it
  ... i think it generally does
  hta: i don't have slides w/
  code
  ... if i have dictionary foo { int blah; }
  ... i can't have additional attributes
  martin__: no one sees the
  dictionary type
  ... so you can have dictionary privatefoo : foo {...}
  hta: they are unobservable?
  fluffy: this applies to any language w/ dictionary inheritance
  ekr: no opinion about
  dictionaries permitting this behavior
  ... it's important to be able to add additional properties
  ... if that can't be made to work, that's death for dictionary
  jan: i think Dictionary doesn't
  have a sequence on purpose
  ... as a useful constraint
  ... you can't know if a caller had a meaning in their sequence or not
  ... a sequential dictionary would be a less restrictive type
  fluffy: write in the spec that objects will inherit from the type defined in the spec
  hta: sold
  adambe: so, StatsReport is a
  map?
  ... and we need unique key for each object?
  hta: key was unique in that object
  juberti: top thing is map->RTCStatsObject
  hta: the dictionary's become interface *RTP* : RTCStatsObject
  martin__: RTCStatsReport is second level of ugly
  hta: it's just a map
  martin__: a map of id's to
  things
  ... but why do we need ids?
  ... why are they the key?
  ... why not rtcstatsobject.type ?
  ... given id's aren't stable across calls
  adambe: at time X
  ... you get a report
  ... check stats for some subreport component
  ... at time Y
  ... you get a report
  ... you want to compare reports
  ... you need to know that stats report is comparable
  "Comment 22"
  martin__: indexing by type
  ... i need to go back to usage patterns
  hta: by id gives you one
  ... by type could give you more
  ... an id could be an implementation defined string/random number
  martin__: but that can be correlated to other stats object at other random times for the same stats object?
  hta: it's the identifier of the underlying object's specific stats property
  <dom> Harald stats v2 proposal
  adambe: how do we define RTCStatsReport ?
  martin__: I think WebIDL has
  operator [index]
  ... or getter()
  hta: i can't say definitely w/o
  `JS the good parts`
  ... i've seen filter()
  ... if primary map is by id, then it's easy to get by type
  adambe: statsreport is only by
  id
  ... people implement by type themselves
  hta: i think my life is simpler
  juberti: what's the timestamp unit?
  hta: `long` is a mistake
  adambe: i argued for DOMTimeStamp
  hta: I argued for Date
  ekr: i'd be sad if i couldn't
  express time in units smaller than ms
  ... requirement is sub-ms resolution
  <dom> High Resolution Time
  juberti: FP or us?
  martin__: nothing native provides one
  dom: High Resolution Time does this
  Josh_Soref: i believe it's from Web Perf
  hta: adopt High Res Time as soon
  as it goes to the list
  ... i implemented this as long and was surprised it didn't overflow
  [ No more slides ]
  juberti: on naming
  ... RTCStatsObject is the parent type
  ... derived types are RTPStream
  ... do we want `Stats` in the names?
  ... i could see having an RTPStream object at a future time
  ... i think they should show that they're Stats
  adambe: how do we keep track of
  remote stats?
  ... are they properties of a local stat
  ... or another property?
  hta: most of the time,
  properties
  ... i defined RTPStream `other end is`
  ... one comes from RTCP and one's local
  ... linking objects together is a special case
  adambe: my preference was to target the remote object directly
  hta: the weird point is
  ... if you get partial stats
  ... sometimes the other side falls outside your filter
  adambe: but you only filter on
  one level
  ... remote shouldn't be null or
  [ scribe is getting lost ]
  hta: if you filter, you get
  n+object graph
  ... you could have stats for other tracks
  ... one case you look up id and it's there
  ... and one case the id isn't there
  ... if there's a point about filtering
  fluffy: i could live with
  this
  ... i'd prefer something more
  ... trying to treat remote stats slightly differently doesn't make sense to me
  ... i'd suggest having 4 sets of statistics ({Local,Remote}{Incoming,Outgoing}RTPStreamStats)
  ... and then stuff all 4 in one object
  hta: if you group, you impose a
  tree structure
  ... i have peerconnection -> streams -> tracks
  ... i have transports -> tracks
  ... not the same mapping
  "relations are good, normal forms are good, trees are bad"
  juberti: on name
  ... type
  ... do we prefer to spell out type
  ... as opposed to instanceof
  ... you have a bunch of RTCStats objects that are more derived
  ... you can look at the parent name property
  ... should we use instanceof?
  Josh_Soref: if you want to duct-type an object, instanceof doesn't work
  martin__: i wrote up an example
  of how to use this
  ... it's clumsy if i'm looking for a particular type
  ... how to figure out which type i'm looking for
  hta: leaf hierarchy
  ... reuse inheritance for more attributes
  ... type field isn't useful anymore
  ... is it incoming, or googlespecial or ...
  ... so we need type documentation
  adambe: some way to tell getstats
  what you want to poll for?
  ... it'd be easier if you could somehow know what to expect
  stefanh: Lunch
  [ +1 +1 +1 ]
  fluffy: is there uncertainty to
  the ietf-stuff
  ... for what to do?
  hta: for stats, adambe needs to
  edit as agreed
  ... adambe and i will have a telco next week
  fluffy: one of you will create a document-ietf mirror of burn
  hta: which registry?
  fluffy: do we create a registry of stats?
  hta: i think we should
  fluffy: expert review?
  TedHardie: there's a W3C side process for creating registries
  adambe: what about additional
  ones
  ... do we want some mandatory stats?
  hta: i think the spec is
  unreadable w/o some examples
  ... the document should register those
  [ Lunch ]
  [ Meeting resumes as IETF after Lunch ]
  TedHardie: we'll try to close
  IETF on-time if not early due to SnowPocalypse
  ... i know we officially scheduled 5
  ... i'd suggest we target resuming @ 1:15