date:20130816

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-16 Thread Yaron Sheffer

[resending as non-HTML]

Hi Paul,

Sorry for the top posting. IMAP ate your mail. Responding to several remaining
points:

- A parser that looks for duplicates must be able to detect that {{a:1, b:2}:4, {b:2,
a:1}:5} does in fact have a duplicate key, because the two internal maps (used as keys) are identical. So in general,
parsers need to canonicalize maps to any depth in order to detect duplicates. This is complex by any definition of
the word.

- Even for an unloved diagnostic notation, you want people to read it without
resorting to little pieces of paper. So a symbolic representation (TAG_URI) is
definitely better than numbers.

- I don't understand your reply re: tags when applied to arrays. Is it up to
the application to decide whether the tag applies to all elements, to the first
one, to the last 14?

- Regarding error handling and security, I am slightly happier with -05, but not by much.
For some reason you avoid using 2119 language in places where I would expect: parsers
SHOULD include a strict mode. A strict mode parser MUST fail when the syntax
is broken (sec. 3.3, 3.4, and also 3.5). And so forth.

- Unknown tags: you specifically allow decoders (Sec. 3.5) to not implement any tags they
don't like, and then you specify the behavior of the decoder as do whatever you
feel like (and this is in -05). So a sender cannot rely on *any* tag being
implemented by the receiver, and cannot expect deterministic behavior if any are not.
This is a security issue IMO, but also an interoperability thing.

Thanks,
Yaron

---

On Aug 13, 2013, at 2:11 PM, Yaron Sheffer yaronf.ietf at gmail.com wrote:

sorry I'm submitting these comments after the end of the LC period. I hope they
can still be of use.

No problem, and the are. Some answers below.

- The diagnostic notation can be used very effectively for things like
configuration files, e.g. if an application already uses CBOR on the wire. Therefore I
would suggest to formalize it a bit more, so that we also have interoperability at this
level.

Based on other things we heard, we went sort of in the other direction in the
next draft: saying that an implementer might consider a different notation for
config files, such as YAML.

- And since this notation is not meant as a JSON extension, this is a good time
to introduce comments (e.g. with an initial '#') into the notation.

Comments are not needed in diagnostics. :-)

- The positive vs. negative encoding means that the parser actually deals with
9-, 17-, 33- and 65-bit integers. I don't think this makes it easier to write
parsers.

If you primarily think about signed integers, that may be one way of viewing
it. CBOR is primarily addressing unsigned integers. Negative integers are
clearly separated out, and indeed do require watching the sign bit. There is
no way to handle this that is painless for all applications.

Multiple people have implemented parsers in multiple languages (JavaScript,
Python, Ruby, ...), and we found it was pretty easy, and very little code.

- Arrays are prefixed by the number of elements but not by their length in
bytes. And elements need not be all of the same size. So you cannot skip the
array without fully parsing every last element. IIRC this is a major
disadvantage compared to ASN.1 encodings.

Correct. Counting items and not bytes is indeed a fundamental design decision
in CBOR that has advantages and disadvantages. We believe the advantages
outweigh the disadvantages.

In specific here, we are not assuming that skip over an array/map is a common
desire for a decoder. Forcing an encoder to marshall all the bytes before it could start
emitting an array/map causes overhead for the encoder that is avoided if it just knows
the number of elements it will emit.

- A puzzling change from JSON, and one that probably complicates
implementations quite a bit, is that a map's index can be of any type, not just
a string. And this includes mixed index types for the same map.

We have looked at this, and do not think that it complicates many
implementations. It does not complicate encoders at all. It does not complicate
decoders, even those that are looking for duplicate keys (which will be an
error). It only complicates decoders that are also sorting the keys. We assume
that the latter does not need to happen in the parser, but in the application
that needs the keys sorted by semantics it knows about.

- And similarly to arrays, you cannot skip a map element without deep parsing
of the element.

Ditto from above.

- I think many of the tag values are too specific, and are best left to
applications. For example, why should the format care if the app encodes a
UTF-8 string in base64?

Because a generic parser could then do the Base64 decoding. This will always be an iffy
space: CBOR will either force too much knowledge on the application, or it will do too
much. We picked somewhere on that continuum, knowing that it

Re: Radical Solution for remote participants

2013-08-16 Thread Joel M. Halpern


Maybe I am missing something.
The reason we have face-to-face meetings is because there is value in 
such meetings that can not reasonably be achieved in other ways.
I would like remote participation to be as good as possible.  But if 
would could achieve the same as being there then we should seriously 
consider not meeting face-to-face.
Conversely, until the technology gets that good, we must not penalize 
the face-to-face meeting for failures of the technology.


Yours,
Joel

On 8/15/13 9:48 PM, Mark Nottingham wrote:


On 13/08/2013, at 11:00 AM, Douglas Otis doug.mtv...@gmail.com wrote:


1) Ensure exact digital interfaces driving projectors are fully available 
remotely.


That would be fantastic, if feasible. Much simpler than sharing through 
software.



2) Ensure Audio access requires an identified request via XMPP prior to 
enabling either a remote or local audio feed.


Hm.



3) RFI tags could facilitate enabling local audio feed instead of an identified 
request via XMPP.


Could be quite interesting; many conferences now provide attendees with RFID 
tags...



4) In the event of the local venue loosing Internet access, the device 
regulating A/V presentations must be able to operate in a virtual mode where 
only remote participants are permitted to continue the meeting proceedings.


That seems… extreme.


5) Important participants should plan for alternative modes of Internet access 
to remain part of the proceedings.


Not exactly practical.



6) Develop a simple syntax used on XMPP sessions to:
1) signify a request to speak on X
2) withdraw a request to speak on X
3) signify support of Y
4) signify non-support of Y
5) signal when a request has been granted or revoked.  For local participants 
this could be in the form of a red or green light at their microphone.


The W3C does much of this already with IRC bots, e.g.:
   http://www.w3.org/2001/12/zakim-irc-bot.html

(also can pick a scribe, track an agenda, etc.)



7) Develop a control panel managed by chairs or their proxies that consolidate 
and sequence requests and log support and nonsupport indications and the 
granting of requests.


See above (I think).



8) Chairs should be able to act as proxies for local participants lacking 
access to XMPP.


Not practical, unless they delegate.



9) Chairs should have alternative Internet access independent of that of the 
venue's.


Seems extreme.



10) Establish a reasonable fee to facilitate remote participants who receive 
credit for their participation equal to that of being local.

11) The device regulating A/V presentations must drive both the video and audio 
portions of the presentations.  A web camera in a room is a very poor 
replacement.

12) All video information in the form of slides and text must be available from 
the Internet prior to the beginning of the meeting.


Cheers,


--
Mark Nottingham   http://www.mnot.net/

Re: Radical Solution for remote participants

2013-08-16 Thread John C Klensin



--On Friday, August 16, 2013 04:59 -0400 Joel M. Halpern
j...@joelhalpern.com wrote:

 Maybe I am missing something.
 The reason we have face-to-face meetings is because there is
 value in such meetings that can not reasonably be achieved in
 other ways.
 I would like remote participation to be as good as possible.
 But if would could achieve the same as being there then we
 should seriously consider not meeting face-to-face.
 Conversely, until the technology gets that good, we must not
 penalize the face-to-face meeting for failures of the
 technology.

Joel,

I certainly agree with your conclusion.  While I hope the intent
wasn't to penalize the face-to-face meeting, there have been
several suggestions in this thread that I believe are
impractical and a few that are probably undesirable even if they
were practical.   Others, such as improved automation, are
practical if we want to make the effort, would probably help,
and, fwiw, have been suggested by multiple people in multiple
threads.

I do believe it would be helpful for everyone involved in the
discussion to be careful about their reactions and rhetoric.
While it is certainly possible to go too far in any given
direction, significant and effective remote participation will
almost certainly require some adjustments by the people in the
room.  We've already made some of those adjustments: for example
while it is inefficient and sometimes doesn't work well, using
Jabber as inbound channel with someone in the room reading
Jabber input at the Mic does help remote participants at some
cost to the efficient flow of the f2f discussions.  

Perhaps that penalizes the face to face participants.  I believe
it is worth it and that it would be worthwhile going somewhat
further in that direction, e.g., by treating remote participants
as a separate mic queue.  I also see it as very closely related
to some other tradeoffs: for example, going to extra effort to
be inclusive and diverse requires extra effort by existing f2f
participants and very carefully balancing costs -- higher costs
and even costs at current levels discourage broader participants
but many ways of increasing diversity also increase costs.

Wrt not meeting face-to-face, I don't see it happening, even
with technology improvements.  On the other hand, the absolutely
most effective thing we could do to significantly decrease costs
for those who need the f2f meetings but are cost-sensitive would
be to reverse the trends toward WG substituting interim meetings
for work on mailing lists, toward extending the IETF meeting
week to include supplemental meetings, and even to move toward
two, rather than three, meetings a year.  Those changes,
especially the latter two, would probably require that remote
participation be much more efficient and effective than it is
today, but would not require nearly the level of perfection
required to eliminate f2f meetings entirely.  And any of the
three would penalize those who like going to extended f2f
meetings and/or prefer working that way and who have effectively
unlimited travel support and related resources.

best,
john

Re: Radical Solution for remote participants

2013-08-16 Thread Hadriel Kaplan


On Aug 13, 2013, at 6:24 AM, John Leslie j...@jlc.net wrote:

   There are a certain number of Working Groups where it's standard
 operating practice to ignore any single voice who doesn't attend an
 IETF week to defend his/her postings.

I don't see that happening in the WGs I attend - when remote participants post 
to jabber, the jabber scribes get mic time.  I think what you mean isn't really 
that physical participants ignore remote ones, but more that remote 
participants don't have as much impact/weight with their input/arguments than 
physical participants do.  Is that what you mean?


   I don't always understand what Doug is asking for; but I suspect
 he is proposing to define a remote-participation where you get full
 opportunity to defend your ideas. This simply doesn't happen today.

Then fix that problem.

Which solution addresses that problem:
1) Make remote participants pay money.
2) Add a separate mic line.
3) Add remote controls for A/V equipment.
4) Add XMPP controls for mic-line and humming.
5) None of the above.

ISTM it's (5).  Working Groups don't ignore remote participant voices because 
they don't pay money.  They don't ignore them because they don't have a 
separate mic.  They don't ignore them because they don't have A/V control.  
They don't ignore them because they don't have XMPP controls.

WG physical participants ignore remote ones because they're not physically 
present.  We're human beings.  Human beings have a subconscious 
connection/empathy with other human beings based on our senses, that does not 
exist when we only read their words or only hear them speaking... especially 
when it's hear them by-proxy as the current jabber model uses.  This isn't news 
to anyone - it's why people travel to meet other people, and why the 
telepresence market exists.

The next step up from our current jabber-scribe model is to have audio input - 
the ability for remote participants to speak using their own voice, when it's 
their turn at the 'mic'.  The next step up after that is video input, where 
remote participants can be seen as well as heard.  Both of those are 
technically achievable, and possibly even practical to implement - though 
that's something the folks who run and manage the meetings would have to 
decide, since they'd know a lot more than us about that.

-hadriel

Re: Radical Solution for remote participants

2013-08-16 Thread Arturo Servin


Well, we just had a technical session about Real Time web.

This seems to me like the perfect application to show and eat own dog 
food.


Regards,
as

On 8/16/13 9:07 AM, Hadriel Kaplan wrote:
 The next step up from our current jabber-scribe model is to have audio input 
 - the ability for remote participants to speak using their own voice, when 
 it's their turn at the 'mic'.  The next step up after that is video input, 
 where remote participants can be seen as well as heard.  Both of those are 
 technically achievable, and possibly even practical to implement - though 
 that's something the folks who run and manage the meetings would have to 
 decide, since they'd know a lot more than us about that.

Charging remote participants

2013-08-16 Thread Hadriel Kaplan


Since the topic keeps getting raised... I think that charging remote 
participants any fee is a really terrible idea.  One of the really great things 
about the IETF is its open and free (as in beer) participation policy.  The 
real work is supposed to be done on mailing lists, and there's no charge or 
restriction on who can send emails.  That policy is actually quite rare for 
standards bodies, and makes our output better not worse.

Obviously we discuss things and do real work at physical meetings too, and 
they're not simply social occasions.  At the end of the day we actually want 
people to come to the physical meetings, but the realities of life make that 
impossible for many.  But charging remote participants for better 
tools/experience isn't the answer.  At least for me, whenever I'm discussing a 
draft mechanism I actually *want* input from remote participants.  I don't want 
it to be only from folks who can afford to provide input.  I want it from 
people who can't get approval for even a $100 expense, from people who are 
between jobs, people from academia, and even from just plain ordinary users 
rather than just vendors or big corps.  At one time we worried that free remote 
participation would lead to too many random participants to get work done, but 
that hasn't become a problem afaict.  Please don't whittle it down further to 
only those who can afford it.

I would do anything whatsoever to avoid charging remote participants, even if 
it means raising the fee for f2f attendees to subsidize remote-participant 
tooling costs.

In that vein, I think a lot of the f2f attendees get our reg-fee paid by our 
employer and another $50 or even $100 isn't going to make a bit of difference 
for us - for those whom it would make a difference, I'd create another category 
of f2f registration fee like 'Self-paying Attendee' or some such.  Selecting 
the new category would drop your fee by the $50 or $100, but wouldn't change 
what gets displayed on your badge or anything.  It would be purely optional, 
with no guilt attached for not paying it and no visible difference to anyone 
else.  Just put some words on the registration form page saying something like 
If you cannot expense your registration fee, please select the 'Self-paying 
Attendee' category or something like that.  Or make it some checkbox thingy.  
I believe the majority of folks who can expense it will not have difficulty 
expensing a 'Regular Attendee' charge so long as it doesn't say we opted to pay 
more.

-hadriel

p.s. Even from a purely practical standpoint, charging remote participants 
raises a lot of issues - we debate incessantly just about the f2f day-pass, and 
that's nothing compared to this.  For example: if things break during the 
meeting session, do we re-imburse them?  Do we pro-rate the re-imbursement 
based on how many of their meetings had technical issues with audio or video?  
Do we charge a flat fee for the whole week of meetings, or just charge per 
meeting session, or depending on how long the session is?  Do we charge 
students a different rate, like we do f2f reg-fees?  Do we need to provide tech 
support with a specific SLA?  This while thing is a can of worms.  It's not 
worth it.

Re: Radical Solution for remote participants

2013-08-16 Thread Hadriel Kaplan


Yes, that had also occurred to me. :)

It does cost money though... if even for just additional equipment, tech 
support and administration, and a separate presentation screen in the rooms.  
And it's one more thing for the folks who run the meetings to worry about, plan 
for, deal with, etc. - and that's a real cost too.  As far as I can tell it's 
not the up-front capex costs of a technology that really matter much, it's the 
recurring opex costs.

-hadriel


On Aug 16, 2013, at 8:30 AM, Arturo Servin arturo.ser...@gmail.com wrote:

 
   Well, we just had a technical session about Real Time web.
 
   This seems to me like the perfect application to show and eat own dog 
 food.
 
   
 Regards,
 as
 
 On 8/16/13 9:07 AM, Hadriel Kaplan wrote:
 The next step up from our current jabber-scribe model is to have audio input 
 - the ability for remote participants to speak using their own voice, when 
 it's their turn at the 'mic'.  The next step up after that is video input, 
 where remote participants can be seen as well as heard.  Both of those are 
 technically achievable, and possibly even practical to implement - though 
 that's something the folks who run and manage the meetings would have to 
 decide, since they'd know a lot more than us about that.

55 matches

Mail list logo