From e559cbe18e88920fb18107a7edf5e28834b47789 Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Tue, 16 Jan 2024 15:18:40 -0800 Subject: [PATCH 1/9] updated papers to applications --- batch/autoassign.php | 6 +-- batch/paperjson.php | 2 +- batch/reviewcsv.php | 2 +- batch/savepapers.php | 4 +- batch/search.php | 2 +- docker/hotcrp-options.php | 8 ++-- etc/distoptions.php | 8 ++-- etc/helptopics.json | 4 +- etc/mailtemplates.json | 2 +- etc/msgs.json | 14 +++--- etc/reviewformlibrary.json | 32 ++++++------- etc/settinginfo.json | 6 +-- scripts/buzzer.js | 2 +- scripts/script.js | 2 +- src/assignmentset.php | 2 +- src/confinvariants.php | 20 ++++----- src/help/h_chairsguide.php | 78 ++++++++++++++++---------------- src/help/h_developer.php | 4 +- src/help/h_formulas.php | 16 +++---- src/help/h_ranking.php | 16 +++---- src/help/h_search.php | 34 +++++++------- src/help/h_tags.php | 92 +++++++++++++++++++------------------- src/help/h_votetags.php | 12 ++--- src/listaction.php | 4 +- src/mailrecipients.php | 12 ++--- src/pages/p_adminhome.php | 4 +- src/pages/p_autoassign.php | 18 ++++---- src/pages/p_bulkassign.php | 6 +-- src/pages/p_home.php | 10 ++--- src/pages/p_log.php | 26 +++++------ src/pages/p_mail.php | 32 ++++++------- src/pages/p_offline.php | 4 +- src/pages/p_paper.php | 4 +- src/pages/p_profile.php | 4 +- src/pages/p_signin.php | 2 +- src/pages/p_users.php | 8 ++-- src/paperlist.php | 2 +- src/papertable.php | 4 +- src/settings/s_banal.php | 8 ++-- src/userstatus.php | 4 +- test/db.json | 44 +++++++++--------- test/emails.txt | 6 +-- test/t_cdb.php | 4 +- 43 files changed, 287 insertions(+), 287 deletions(-) diff --git a/batch/autoassign.php b/batch/autoassign.php index 4c946d44a..1fe5b798d 100644 --- a/batch/autoassign.php +++ b/batch/autoassign.php @@ -96,7 +96,7 @@ function run() { } $pids = $srch->paper_ids(); if (empty($pids)) { - throw new CommandLineException("No papers match that search"); + throw new CommandLineException("No applications match that search"); } if (empty($this->pcc)) { @@ -159,8 +159,8 @@ static function make_args($argv) { "config: !", "dry-run,d Do not perform assignment; output CSV instead.", "a:,autoassigner: =AA Use autoassigner AA.", - "q:,search: =QUERY Use papers matching QUERY.", - "all Search all papers (default is to search submitted papers).", + "q:,search: =QUERY Use applications matching QUERY.", + "all Search all applications (default is to search submitted applications).", "u[],user[] =USER Include users matching USER (`-USER` excludes).", "c:,count: {n} =N Set `count` parameter to N.", "t:,type: =TYPE Set `type`/`rtype` parameter to TYPE.", diff --git a/batch/paperjson.php b/batch/paperjson.php index a843af69f..b4b298aec 100644 --- a/batch/paperjson.php +++ b/batch/paperjson.php @@ -93,7 +93,7 @@ static function make_args($argv) { "t:,type: =COLLECTION Search COLLECTION ‘s’ or ‘all’ [submitted]", "1,single Output first matching paper rather than an array", "help,h" - )->description("Output a JSON file with papers matching SEARCH. + )->description("Output a JSON file with applications matching SEARCH. Usage: php batch/paperjson.php [-t all] [-1] [SEARCH...]") ->helpopt("help") ->parse($argv); diff --git a/batch/reviewcsv.php b/batch/reviewcsv.php index 2a0967df0..6063d209a 100644 --- a/batch/reviewcsv.php +++ b/batch/reviewcsv.php @@ -304,7 +304,7 @@ static function run_args($argv) { "no-score Omit score fields", "no-header Omit CSV header", "format: =FMT Only output text fields with format FMT" - )->description("Output CSV containing all reviews for papers matching QUERY. + )->description("Output CSV containing all reviews for applications matching QUERY. Usage: php batch/reviewcsv.php [-acx] [QUERY...]") ->helpopt("help") ->parse($argv); diff --git a/batch/savepapers.php b/batch/savepapers.php index 24f133bfc..722ba5b89 100644 --- a/batch/savepapers.php +++ b/batch/savepapers.php @@ -293,11 +293,11 @@ static function run_args($argv) { "ignore-errors Don’t exit after first error", "disable-users,disable Disable all newly created users", "ignore-pid Ignore `pid` JSON elements", - "match-title Match papers by title if no `pid`", + "match-title Match applications by title if no `pid`", "add-topics Add all referenced topics to conference", "no-log Don’t modify the action log" )->helpopt("help") - ->description("Change papers as specified by FILE, a JSON object or array of objects. + ->description("Change applications as specified by FILE, a JSON object or array of objects. Usage: php batch/savepapers.php [OPTIONS] [FILE]") ->maxarg(1) ->parse($argv); diff --git a/batch/search.php b/batch/search.php index 15a086e80..3ed8613d6 100644 --- a/batch/search.php +++ b/batch/search.php @@ -68,7 +68,7 @@ function run() { static function help() { fwrite(STDOUT, "Usage: php batch/search.php [-n CONFID] [-t COLLECTION] [-f FIELD]+ [QUERY...] -Output a CSV file containing the FIELDs for the papers matching QUERY. +Output a CSV file containing the FIELDs for the applications matching QUERY. Options include: -t, --type COLLECTION Search COLLECTION “s” (submitted) or “all” [s]. diff --git a/docker/hotcrp-options.php b/docker/hotcrp-options.php index 56c5e7677..b46c675e2 100644 --- a/docker/hotcrp-options.php +++ b/docker/hotcrp-options.php @@ -41,7 +41,7 @@ // number. Examples: "SIGCOMM 2007", "HotNets V". // longName Longer name of the conference. Example: "ACM SIGCOMM // 2007 Conference". -// downloadPrefix Prefix for downloaded files, such as papers; should +// downloadPrefix Prefix for downloaded files, such as applications; should // end in a dash. Example: "hotnets5-". Defaults to // $Opt["dbName"] plus a dash. // paperSite [OPTIONAL] URL for this HotCRP installation. Used in @@ -121,7 +121,7 @@ // PAPER STORAGE // -// docstore Set to true to serve papers and other downloads from a +// docstore Set to true to serve applications and other downloads from a // cache on the local filesystem. By default this cache is // created in the "docs" directory. You can also set // $Opt["docstore"] to a directory name. @@ -131,7 +131,7 @@ // s3_bucket Amazon S3 bucket name to store paper submissions. // s3_key Amazon AWS access key ID (used for S3). // s3_secret Amazon AWS secret access key (used for S3). -// dbNoPapers Set to true to not store papers in the database. +// dbNoPapers Set to true to not store applications in the database. // Requires filestore, S3 storage, or both. @@ -186,7 +186,7 @@ // strictJavascript If true, send Javascript with "use strict". // hideManager If set, PC members are not shown paper managers. // disableCapabilities If set, emails to authors will not have a -// token enabling them to view their papers without logging in. +// token enabling them to view their applications without logging in. $Opt["smartScoreCompare"] = true; diff --git a/etc/distoptions.php b/etc/distoptions.php index b3690a1a2..62fc2c4e2 100644 --- a/etc/distoptions.php +++ b/etc/distoptions.php @@ -35,7 +35,7 @@ // number. Examples: "SIGCOMM 2007", "HotNets V". // longName Longer name of the conference. Example: "ACM SIGCOMM // 2007 Conference". -// downloadPrefix Prefix for downloaded files, such as papers; should +// downloadPrefix Prefix for downloaded files, such as applications; should // end in a dash. Example: "hotnets5-". Defaults to // $Opt["dbName"] plus a dash. // paperSite [OPTIONAL] URL for this HotCRP installation. Used in @@ -111,7 +111,7 @@ // PAPER STORAGE // -// docstore Set to true to serve papers and other downloads from a +// docstore Set to true to serve applications and other downloads from a // cache on the local filesystem. By default this cache is // created in the "docs" directory. You can also set // $Opt["docstore"] to a directory name. @@ -121,7 +121,7 @@ // s3_bucket Amazon S3 bucket name to store paper submissions. // s3_key Amazon AWS access key ID (used for S3). // s3_secret Amazon AWS secret access key (used for S3). -// dbNoPapers Set to true to not store papers in the database. +// dbNoPapers Set to true to not store applications in the database. // Requires filestore, S3 storage, or both. @@ -176,7 +176,7 @@ // strictJavascript If true, send Javascript with "use strict". // hideManager If set, PC members are not shown paper managers. // disableCapabilities If set, emails to authors will not have a -// token enabling them to view their papers without logging in. +// token enabling them to view their applications without logging in. $Opt["smartScoreCompare"] = true; diff --git a/etc/helptopics.json b/etc/helptopics.json index 7f11597c1..455d550cd 100644 --- a/etc/helptopics.json +++ b/etc/helptopics.json @@ -280,13 +280,13 @@ { "name": "revrate", "alias": "reviewratings" }, { "name": "votetags", "title": "Voting", - "description": "<0>PC members can vote for papers using tags.", + "description": "<0>PC members can vote for applications using tags.", "print_function": "VoteTags_HelpTopic::print", "order": 8000 }, { "name": "ranking", "title": "Ranking", - "description": "<0>PC members can rank papers using tags.", + "description": "<0>PC members can rank applications using tags.", "print_function": "Ranking_HelpTopic::print", "order": 9000 }, diff --git a/etc/mailtemplates.json b/etc/mailtemplates.json index 2fd48df8f..8a027b714 100644 --- a/etc/mailtemplates.json +++ b/etc/mailtemplates.json @@ -725,7 +725,7 @@ "* Title: %TITLE%\n", "* Author(s): %OPT(AUTHORS)%\n", "* Site: %URL(paper, p=%NUMBER%, %AUTHORVIEWCAPABILITY%)%\n\n", - "%NUMACCEPTED% papers were accepted out of %NUMSUBMITTED% submissions.\n\n", + "%NUMACCEPTED% applications were accepted out of %NUMSUBMITTED% submissions.\n\n", "Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below.\n\n", "Contact %ADMIN% with any questions or concerns.\n\n", "%SIGNATURE%\n\n", diff --git a/etc/msgs.json b/etc/msgs.json index 5e8dc7da4..2ab1dfa55 100644 --- a/etc/msgs.json +++ b/etc/msgs.json @@ -17,7 +17,7 @@ ["You can’t register submission #%d yet.", "You can’t register submissions yet.", ["$1<0"]], ["You can’t register submission #%d until %s.", "You can’t register submissions until %2$s.", ["$1<0"]], - ["%d papers accepted out of %d submitted.", "%d paper accepted out of %d submitted.", ["$1=1"]], + ["%d applications accepted out of %d submitted.", "%d application accepted out of %d submitted.", ["$1=1"]], ["%s review deadline", "Review deadline", ["!$1"]], ["%s reviews are requested by this deadline.", "Reviews are requested by this deadline.", ["!$1"]], ["%s review hard deadline", "Review hard deadline", ["!$1"]], @@ -164,14 +164,14 @@ {"id": "conflictdef", "itext": "This includes past advisors and students, people with the same affiliation, and any recent (~2 years) coauthors and collaborators.", "template": true}, - {"id": "finalsubmit", "itext": "Congratulations! The paper has been accepted. Update the paper’s final version here. {deadline} You may also edit paper contacts, allowing others to view reviews and make changes."}, + {"id": "finalsubmit", "itext": "Congratulations! The application has been accepted. Update the application’s final version here. {deadline} You may also edit application contacts, allowing others to view reviews and make changes."}, - {"id": "revprefdescription", "itext": "

A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order. Different users’ preference values are not compared and need not use the same scale.

\n\n

Select a column heading to sort by that column. Enter preferences in the text boxes or on the paper pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the paper list.

", "format": 5}, - {"id": "revprefdescription", "itext": "

A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order, using topic scores to break ties. Different users’ preference values are not compared and need not use the same scale.

\n\n

The list shows all submissions and their topics (high interest topics, low interest topics). “Topic score” summarizes your interest in the submission’s topics. Select a column heading to sort by that column. Enter preferences in the text boxes or on the paper pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the paper list.

", "require": ["$1"], "format": 5}, + {"id": "revprefdescription", "itext": "

A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order. Different users’ preference values are not compared and need not use the same scale.

\n\n

Select a column heading to sort by that column. Enter preferences in the text boxes or on the application pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the application list.

", "format": 5}, + {"id": "revprefdescription", "itext": "

A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order, using topic scores to break ties. Different users’ preference values are not compared and need not use the same scale.

\n\n

The list shows all submissions and their topics (high interest topics, low interest topics). “Topic score” summarizes your interest in the submission’s topics. Select a column heading to sort by that column. Enter preferences in the text boxes or on the application pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the application list.

", "require": ["$1"], "format": 5}, - ["external_review_request_description", "External reviewers may view their assigned papers. Before requesting an external review, you should generally check whether they are interested."], - ["external_review_request_description", "External reviewers may view their assigned papers, including other reviews and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0"]], - ["external_review_request_description", "External reviewers may view their assigned papers, including other reviews and reviewer identities and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0", "setting.extrev_seerevid>0"]], + ["external_review_request_description", "External reviewers may view their assigned applications. Before requesting an external review, you should generally check whether they are interested."], + ["external_review_request_description", "External reviewers may view their assigned applications, including other reviews and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0"]], + ["external_review_request_description", "External reviewers may view their assigned applications, including other reviews and reviewer identities and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0", "setting.extrev_seerevid>0"]], ["(%d more permissions have default values)", "(%d more permission has default value)", ["$1=1"]], diff --git a/etc/reviewformlibrary.json b/etc/reviewformlibrary.json index 4472a812f..56bfc646f 100644 --- a/etc/reviewformlibrary.json +++ b/etc/reviewformlibrary.json @@ -80,9 +80,9 @@ "type": "radio", "values": [ "Reject", - "Weak paper, though I will not fight strongly against it", - "OK paper, but I will not champion it", - "Good paper, I will champion it" + "Weak application, though I will not fight strongly against it", + "OK application, but I will not champion it", + "Good application, I will champion it" ], "start": "A", "required": true, @@ -94,11 +94,11 @@ "name": "Overall merit", "type": "radio", "values": [ - "Bottom 50% of submitted papers", - "Top 50% but not top 25% of submitted papers", - "Top 25% but not top 10% of submitted papers", - "Top 10% but not top 5% of submitted papers", - "Top 5% of submitted papers!" + "Bottom 50% of submitted applications", + "Top 50% but not top 25% of submitted applications", + "Top 25% but not top 10% of submitted applications", + "Top 10% but not top 5% of submitted applications", + "Top 5% of submitted applications!" ], "required": true, "visibility": "au" @@ -146,17 +146,17 @@ "scheme": "orbu" }, { - "selector": "Paper summary", - "name": "Paper summary", + "selector": "Application summary", + "name": "Application summary", "type": "text", - "description": "Please summarize the paper’s main results in your own words. This will frame the review and show that you have understood the paper’s intent.", + "description": "Please summarize the application’s main results in your own words. This will frame the review and show that you have understood the application’s intent.", "visibility": "au" }, { - "selector": "Paper summary (shorter description)", - "name": "Paper summary", + "selector": "Applications summary (shorter description)", + "name": "Application summary", "type": "text", - "description": "Please summarize the paper briefly in your own words.", + "description": "Please summarize the application briefly in your own words.", "visibility": "au" }, { @@ -224,14 +224,14 @@ "selector": "Strengths", "name": "Strengths", "type": "text", - "description": "What are the paper’s important strengths? Just a couple sentences, please.", + "description": "What are the application’s important strengths? Just a couple sentences, please.", "visibility": "au" }, { "selector": "Weaknesses", "name": "Weaknesses", "type": "text", - "description": "What are the paper’s important weaknesses? Just a couple sentences, please.", + "description": "What are the application’s important weaknesses? Just a couple sentences, please.", "visibility": "au" } ] diff --git a/etc/settinginfo.json b/etc/settinginfo.json index 9e2df69cc..7937e1655 100644 --- a/etc/settinginfo.json +++ b/etc/settinginfo.json @@ -487,7 +487,7 @@ }, { "name": "review_self_assign", "storage": "pcrev_any", - "title": "PC can review any paper", + "title": "PC can review any application", "type": "checkbox", "initial_value": 1 }, { @@ -847,7 +847,7 @@ }, { "name_pattern": "format/$/papersize", - "title": "PDF format checker paper size", + "title": "PDF format checker application size", "type": "string", "size": 18, "placeholder": "any" }, { @@ -959,7 +959,7 @@ }, { "name": "tag_visibility_conflict", "storage": "tag_seeall", - "title": "PC can see tags for conflicted papers", + "title": "PC can see tags for conflicted applications", "type": "checkbox" }, { diff --git a/scripts/buzzer.js b/scripts/buzzer.js index 5c9a9daa7..fcb904cf9 100644 --- a/scripts/buzzer.js +++ b/scripts/buzzer.js @@ -211,7 +211,7 @@ function do_kiosk() { hc.push('

Kiosk mode is a discussion status page with no other site privileges. It’s safe to leave a browser in kiosk mode open in the hallway.

'); hc.push('

Kiosk mode will sign your browser out of the site. Do not use kiosk mode on your main browser.

'); hc.push('

These URLs access kiosk mode directly:

'); - hc.push('
With papers
' + escape_html(info.kiosk_urls[1]) + hc.push('
With applications
' + escape_html(info.kiosk_urls[1]) + '
Conflicts only
' + escape_html(info.kiosk_urls[0]) + '
'); if (show_papers) diff --git a/scripts/script.js b/scripts/script.js index cb6dca3f2..983eb33cd 100644 --- a/scripts/script.js +++ b/scripts/script.js @@ -3287,7 +3287,7 @@ handle_ui.on("js-tracker", function (evt) { hc.push('PC members without tag ' + vis.substring(1)); hc.push_pop('
This setting restricts all trackers.
'); } - hc.push('
'); + hc.push('
'); if (tr.start_at) hc.push('
'); try { diff --git a/src/assignmentset.php b/src/assignmentset.php index d271eb01f..f1251ca8a 100644 --- a/src/assignmentset.php +++ b/src/assignmentset.php @@ -1479,7 +1479,7 @@ private function collect_papers($pfield, &$pids, $report_error) { $val = 1; } if (empty($npids) && $report_error) { - $this->astate->warning("<0>No papers match ‘{$pfield}’"); + $this->astate->warning("<0>No applications match ‘{$pfield}’"); } // Implement paper restriction diff --git a/src/confinvariants.php b/src/confinvariants.php index ec72339fe..d6bb21d27 100644 --- a/src/confinvariants.php +++ b/src/confinvariants.php @@ -102,13 +102,13 @@ function check_summary_settings() { // `no_papersub` === no submitted papers $any = $this->invariantq("select paperId from Paper where timeSubmitted>0 limit 1"); if ($any !== !($this->conf->setting("no_papersub") ?? false)) { - $this->invariant_error("no_papersub", "paper #{0} is submitted but no_papersub is true", "no paper is submitted but no_papersub is false"); + $this->invariant_error("no_papersub", "application #{0} is submitted but no_papersub is true", "no application is submitted but no_papersub is false"); } // `paperacc` === any accepted submitted papers $any = $this->invariantq("select paperId from Paper where outcome>0 and timeSubmitted>0 limit 1"); if ($any !== !!($this->conf->setting("paperacc") ?? false)) { - $this->invariant_error("paperacc", "paper #{0} is accepted but paperacc is false", "no paper is accepted but paperacc is true"); + $this->invariant_error("paperacc", "application #{0} is accepted but paperacc is false", "no application is accepted but paperacc is true"); } // `rev_tokens` === any papers with reviewToken @@ -155,7 +155,7 @@ function check_papers() { // submitted xor withdrawn $any = $this->invariantq("select paperId from Paper where timeSubmitted>0 and timeWithdrawn>0 limit 1"); if ($any) { - $this->invariant_error("submitted_withdrawn", "paper #{0} is both submitted and withdrawn"); + $this->invariant_error("submitted_withdrawn", "application #{0} is both submitted and withdrawn"); } // `dataOverflow` is JSON @@ -190,7 +190,7 @@ function check_papers() { // no unknown decisions $any = $this->invariantq("select paperId, outcome from Paper where outcome?A", $this->conf->decision_set()->ids()); if ($any) { - $this->invariant_error("unknown_decision", "paper #{0} with unknown outcome #{1}"); + $this->invariant_error("unknown_decision", "application #{0} with unknown outcome #{1}"); } return $this; @@ -364,14 +364,14 @@ function check_documents() { assert(count($this->irow) === 10); for ($n = 2; $n !== 6 && $this->irow[$n] === $this->irow[$n + 4]; ++$n) { } - $this->invariant_error("paper_denormalization", "bad Paper denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})"); + $this->invariant_error("paper_denormalization", "bad Application denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})"); } $any = $this->invariantq("select p.paperId, ps.paperStorageId, p.sha1, p.size, p.mimetype, p.timestamp, ps.sha1, ps.size, ps.mimetype, ps.timestamp from Paper p join PaperStorage ps on (ps.paperStorageId=p.finalPaperStorageId) where p.finalPaperStorageId>1 and (p.sha1!=ps.sha1 or p.size!=ps.size or p.mimetype!=ps.mimetype or p.timestamp!=ps.timestamp) limit 1"); if ($any) { assert(count($this->irow) === 10); for ($n = 2; $n !== 6 && $this->irow[$n] === $this->irow[$n + 4]; ++$n) { } - $this->invariant_error("paper_denormalization", "bad Paper final denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})"); + $this->invariant_error("paper_denormalization", "bad Application final denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})"); } // filterType is never zero @@ -505,7 +505,7 @@ function check_document_inactive() { sort($pids); $any = $this->invariantq("select s.paperId, s.paperStorageId from PaperStorage s where s.paperStorageId?a and s.inactive limit 1", $pids); if ($any) { - $this->invariant_error("inactive", "paper {0} document {1} is inappropriately inactive"); + $this->invariant_error("inactive", "application {0} document {1} is inappropriately inactive"); } $oids = $nonempty_oids = []; @@ -520,19 +520,19 @@ function check_document_inactive() { if (!empty($oids)) { $any = $this->invariantq("select o.paperId, o.optionId, s.paperStorageId from PaperOption o join PaperStorage s on (s.paperStorageId=o.value and s.inactive and s.paperStorageId>1) where o.optionId?a limit 1", $oids); if ($any) { - $this->invariant_error("inactive", "paper {0} option {1} document {2} is inappropriately inactive"); + $this->invariant_error("inactive", "application {0} option {1} document {2} is inappropriately inactive"); } $any = $this->invariantq("select o.paperId, o.optionId, s.paperStorageId, s.paperId from PaperOption o join PaperStorage s on (s.paperStorageId=o.value and s.paperStorageId>1 and s.paperId!=o.paperId) where o.optionId?a limit 1", $oids); if ($any) { - $this->invariant_error("paper {0} option {1} document {2} belongs to different paper {3}"); + $this->invariant_error("application {0} option {1} document {2} belongs to different application {3}"); } } if (!empty($nonempty_oids)) { $any = $this->invariantq("select o.paperId, o.optionId from PaperOption o where o.optionId?a and o.value<=1 limit 1", $nonempty_oids); if ($any) { - $this->invariant_error("paper {0} option {1} links to empty document"); + $this->invariant_error("application {0} option {1} links to empty document"); } } diff --git a/src/help/h_chairsguide.php b/src/help/h_chairsguide.php index c0a447f60..6ff2de895 100644 --- a/src/help/h_chairsguide.php +++ b/src/help/h_chairsguide.php @@ -57,7 +57,7 @@ static function print_presubmission(HelpRenderer $hth, $gj) {

  • Additional fields such as checkboxes, selectors, freeform text, and uploaded attachments. Checkbox fields might include “Consider - this paper for the Best Student Paper award” or “Provide this paper to the + this application for the Best Student Application award” or “Provide this application to the European shadow PC.” Attachment fields might include supplemental material. You can search for submissions with or without each field.

    • @@ -89,9 +89,9 @@ static function print_assignments(HelpRenderer $hth, $gj) { echo "\n\n"; } else if ($gj->itemid === 1) { - echo "

  • Consider checking ", $hth->search_link("the papers", ["q" => "", "t" => "all"]), + echo "

  • Consider checking ", $hth->search_link("the applications", ["q" => "", "t" => "all"]), " for anomalies. Withdraw and/or delete duplicates or update details on the ", - $hth->hotlink("paper pages", "paper"), " (via “Edit paper”). + $hth->hotlink("application applications", "paper"), " (via “Edit paper”). Also consider contacting the authors of ", $hth->search_link("incomplete submissions", ["q" => "status:unsub", "t" => "all"]), ", especially if a PDF document was uploaded; sometimes a @@ -101,7 +101,7 @@ static function print_assignments(HelpRenderer $hth, $gj) { echo "

  • Check for formatting violations (optional). ", $hth->hotlink("Search", "search", "q="), " > Download > Format check will download a summary report. Serious errors - are also shown on paper pages (problematic PDFs are distinguished by an + are also shown on application pages (problematic PDFs are distinguished by an “X”).

    • \n"; } else if ($gj->itemid === 3) { @@ -111,29 +111,29 @@ static function print_assignments(HelpRenderer $hth, $gj) { } else if ($gj->itemid === 4) { echo "

  • ", $hth->setting_group_link("Set review policies and deadlines", "reviews"), ", including reviewing deadlines, - review anonymity, and whether PC members may review any paper + review anonymity, and whether PC members may review any application (usually “yes” is the right answer).

    • \n"; } else if ($gj->itemid === 5) { echo "

  • ", $hth->setting_link("Prepare tracks (optional).", "track"), " Tracks give chairs fine-grained control over PC - members’ access rights for individual papers. Example situations calling for + members’ access rights for individual applications. Example situations calling for tracks include external review committees, PC-paper review committees, and multi-track conferences.

    • \n"; } else if ($gj->itemid === 6) { echo "

  • ", $hth->hotlink("Collect review preferences from the PC.", "reviewprefs"), " PC members can enter per-paper review preferences (also known as bids) to - mark papers they want or don’t want to review. Preferences are integers, typically + mark applications they want or don’t want to review. Preferences are integers, typically in the range −20 to 20; the higher the number, the more desired the review assignment. Users can either set their preferences ", $hth->hotlink("all at once", "reviewprefs"), ", or (often more - convenient) page through the ", $hth->search_link("list of submitted papers", ""), - " and set their preferences on the ", $hth->hotlink("paper pages", "paper"), ".

    + convenient) page through the ", $hth->search_link("list of submitted applications", ""), + " and set their preferences on the ", $hth->hotlink("application applications", "paper"), ".

    If desired, review preferences can be collected before the submission - deadline. Select ", $hth->setting_link("“PC can see all registered papers until submission deadline”", "draft_submission_early_visibility"), - ", which allows PC members to see abstracts for registered papers that haven’t yet + deadline. Select ", $hth->setting_link("“PC can see all registered applications until submission deadline”", "draft_submission_early_visibility"), + ", which allows PC members to see abstracts for registered applications that haven’t yet been submitted.

    • \n"; } else if ($gj->itemid === 7) { @@ -143,7 +143,7 @@ static function print_assignments(HelpRenderer $hth, $gj) { such conflicts.

    \n"; } else if ($gj->itemid === 8) { - echo "

  • ", $hth->hotlink("Assign reviews.", "manualassign"), " You can make assignments ", $hth->hotlink("by paper", "assign"), ", ", + echo "

  • ", $hth->hotlink("Assign reviews.", "manualassign"), " You can make assignments ", $hth->hotlink("by application", "assign"), ", ", $hth->hotlink("by PC member", "manualassign"), ", ", $hth->hotlink("by uploading an assignment file", "bulkassign"), ", or, even easier, ", $hth->hotlink("automatically", "autoassign"), ". PC @@ -155,7 +155,7 @@ static function print_assignments(HelpRenderer $hth, $gj) {

    The assignment pages apply to all submissions by default. You can also assign groups of submissions, such as ", - $hth->search_link("papers with fewer than three completed reviews", "cre:<3"), + $hth->search_link("applications with fewer than three completed reviews", "cre:<3"), ".

    • \n"; } else if ($gj->itemid === 9) { @@ -166,21 +166,21 @@ static function print_assignments(HelpRenderer $hth, $gj) { static function print_chair_conflicts(HelpRenderer $hth) { echo $hth->subhead("Chair conflicts"); echo "

    Chairs and system administrators can access any information stored in the -conference system, including reviewer identities for conflicted papers. +conference system, including reviewer identities for conflicted applications. It is easiest to simply accept such conflicts as a fact of life. Chairs who can’t handle conflicts fairly shouldn’t be chairs. However, HotCRP does offer other mechanisms for conflicted reviews.

    -

    First, each paper can be assigned a paper administrator: a PC member -who manages that paper’s reviewing and discussion. Use the left-hand side of a ", +

    First, each application can be assigned a application administrator: a PC member +who manages that application’s reviewing and discussion. Use the left-hand side of a ", $hth->hotlink("submission’s assignment page", "assign"), " to enter its administrator. (You may need to “Override conflicts” to access the assignment page.) -Paper administrators have full privilege to assign and view reviews for their -papers, and can, for example, use the autoassignment tool, but they cannot change -conference settings. When a paper +Application administrators have full privilege to assign and view reviews for their +applications, and can, for example, use the autoassignment tool, but they cannot change +conference settings. When a application has an administrator, chair conflicts cannot be overridden.

    -

    Paper administrators make life easy for PC reviewers and greatly restrict +

    Application administrators make life easy for PC reviewers and greatly restrict conflicted chairs’ access. Usually this suffices. For additional privacy, use review tokens, which are completely anonymous @@ -190,10 +190,10 @@ static function print_chair_conflicts(HelpRenderer $hth) { or email address. This reports the token, a short string of letters and numbers such as “9HDZYUB”. Any user who knows the token can enter it on HotCRP’s home page, after which the system lets them -view the paper and anonymously modify the corresponding “Jane Q. Public” +view the application and anonymously modify the corresponding “Jane Q. Public” review. True reviewer identities will not appear in HotCRP’s database or its logs. -For even more privacy, the paper administrator could collect +For even more privacy, the application administrator could collect offline review forms via email and upload them using review tokens; then even web server access logs store only the administrator’s identity.

    \n\n"; @@ -218,17 +218,17 @@ static function print_premeeting(HelpRenderer $hth, $gj) { } else if ($gj->itemid === 2) { echo "

  • Set ", $hth->setting_link("PC can see review contents", "review_visibility_pc"), " to “Yes” (optional). This opens up the reviews to the program committee, - allowing everyone to see scores and read reviews for non-conflicted papers. - (During most conferences’ review periods, a PC member can see a paper’s reviews - only after completing their own review for that paper.)

    • \n"; + allowing everyone to see scores and read reviews for non-conflicted applications. + (During most conferences’ review periods, a PC member can see a application’s reviews + only after completing their own review for that application.)

    \n"; } else if ($gj->itemid === 3) { - echo "

  • ", $hth->search_link("Examine paper scores", "show:scores"), + echo "

  • ", $hth->search_link("Examine application scores", "show:scores"), ", either one at a time or en masse, and decide - which papers will be discussed. The ", $hth->help_link("tags", "tags"), - " system can group papers and prepare discussion sets. + which applications will be discussed. The ", $hth->help_link("tags", "tags"), + " system can group applications and prepare discussion sets. Use ", $hth->help_link("search keywords", "keywords"), " to, for example, - find all papers with at least two overall merit ratings of 2 or better.

    • \n"; + find all applications with at least two overall merit ratings of 2 or better.

    \n"; } else if ($gj->itemid === 4) { echo "

  • Assign discussion orders using ", $hth->help_link("tags", "tags#values"), @@ -240,15 +240,15 @@ static function print_premeeting(HelpRenderer $hth, $gj) { } else if ($gj->itemid === 5) { echo "

  • ", $hth->hotlink("Assign discussion leads (optional).", "autoassign"), " Discussion leads are expected to be able to - summarize the paper and the reviews. You can assign leads either ", - $hth->hotlink("paper by paper", "assign"), " or ", + summarize the application and the reviews. You can assign leads either ", + $hth->hotlink("application by application", "assign"), " or ", $hth->hotlink("automatically", "autoassign"), ".

    • \n"; } else if ($gj->itemid === 6) { echo "

  • ", $hth->setting_link("Define decision types (optional).", "decision"), " By default, HotCRP has two decision types, “accept” and “reject,” but you can add other types of acceptance and - rejection, such as “accept as short paper.”

    • \n"; + rejection, such as “accept as short application.”

    \n"; } else if ($gj->itemid === 7) { echo "

  • The night before the meeting, ", $hth->search_link("download all reviews onto a laptop", ""), @@ -269,9 +269,9 @@ static function print_atmeeting(HelpRenderer $hth, $gj) { } else if ($gj->itemid === 1) { echo "

  • The meeting tracker can keep the PC coordinated by sharing your browser’s status. - Search for papers in whatever order you like (you may want an explicit ", + Search for applications in whatever order you like (you may want an explicit ", $hth->help_link("discussion order", "tags#values"), "), - navigate to the first paper in + navigate to the first application in the order, and select “☟” to activate the tracker in that tab. As you use that tab to navigate through the order, its current position is broadcast to all logged-in PC members’ browsers:

    @@ -285,15 +285,15 @@ static function print_atmeeting(HelpRenderer $hth, $gj) { reference.

    • \n"; } else if ($gj->itemid === 3) { - echo "

  • Paper decisions can be recorded on the ", - $hth->hotlink("paper pages", "review"), " or en masse via ", + echo "

  • Application decisions can be recorded on the ", + $hth->hotlink("application applications", "review"), " or en masse via ", $hth->search_link("search", ""), ". Use ", $hth->setting_link("decision settings", "decision_visibility_author"), " to expose decisions to PC members if desired.

    • \n"; } else if ($gj->itemid === 4) { echo "

  • Shepherding (optional). If your conference uses - shepherding for accepted papers, you can assign shepherds either ", - $hth->hotlink("paper by paper", "paper"), " or ", $hth->hotlink("automatically", "autoassign", "t=accepted"), ".

    • \n"; + shepherding for accepted applications, you can assign shepherds either ", + $hth->hotlink("application by application", "paper"), " or ", $hth->hotlink("automatically", "autoassign", "t=accepted"), ".

    \n"; } } @@ -326,7 +326,7 @@ static function print_postmeeting(HelpRenderer $hth, $gj) { themselves.

    \n"; } else if ($gj->itemid === 5) { - echo "

  • ", $hth->setting_link("Collect final papers (optional).", "final_open"), + echo "

  • ", $hth->setting_link("Collect final applications (optional).", "final_open"), " If you’re putting together the program yourself, it can be convenient to collect final versions using HotCRP. Authors upload final versions just as they did submissions. You can then ", diff --git a/src/help/h_developer.php b/src/help/h_developer.php index 4407ed5ca..9735c7dc5 100644 --- a/src/help/h_developer.php +++ b/src/help/h_developer.php @@ -93,8 +93,8 @@ function print_settings() { function print_submissions() { echo "

    The api/paper endpoint accesses conference submissions. GET calls return paper information; use -api/PAPERID/paper to return one paper, and -api/paper?q=SEARCH&t=SEARCHTYPE to return all papers matching +api/PAPERID/paper to return one application, and +api/paper?q=SEARCH&t=SEARCHTYPE to return all applications matching SEARCH.

    "; } } diff --git a/src/help/h_formulas.php b/src/help/h_formulas.php index 08176fd1d..2732b7f0d 100644 --- a/src/help/h_formulas.php +++ b/src/help/h_formulas.php @@ -5,17 +5,17 @@ class Formulas_HelpTopic { static function print(HelpRenderer $hth) { echo "

    Program committee members and administrators can search and display formulas -that calculate properties of paper scores—for instance, the -standard deviation of papers’ Overall merit scores, or average Overall +that calculate properties of application scores—for instance, the +standard deviation of applications’ Overall merit scores, or average Overall merit among reviewers with high Reviewer expertise.

    To display a formula, use a search term such as “", $hth->search_link("show:var(OveMer)"), "” (show -the variance in Overall merit scores, along with statistics for all papers). +the variance in Overall merit scores, along with statistics for all applications). You can also ", $hth->hotlink("graph formulas", "graph", "group=formula"), ". To search for a formula, use a search term such as “", $hth->search_link("formula:var(OveMer)>0.5"), "” -(select papers with variance in Overall merit greater than 0.5). +(select applications with variance in Overall merit greater than 0.5). Or save formulas using ", $hth->search_link("Search > View options", ["q" => "", "#" => "view"]), " > Edit formulas.

    @@ -77,8 +77,8 @@ static function print(HelpRenderer $hth) { echo $hth->trow("topics:text", "Number of topics matching text"); } echo $hth->tgroup("Tags"); - echo $hth->trow("#tagname", "True if this paper has tag tagname"); - echo $hth->trow("tagval:tagname", "The value of tag tagname, or null if this paper doesn’t have that tag"); + echo $hth->trow("#tagname", "True if this application has tag tagname"); + echo $hth->trow("tagval:tagname", "The value of tag tagname, or null if this application doesn’t have that tag"); echo $hth->tgroup("Scores"); echo $hth->trow("overall-merit", "This review’s Overall merit score
    Only completed reviews are considered.
    "); echo $hth->trow("OveMer", "Abbreviations also accepted"); @@ -103,9 +103,9 @@ static function print(HelpRenderer $hth) { echo $hth->subhead("Aggregate functions"); echo "

    Aggregate functions calculate a -value based on all of a paper’s reviews and/or review preferences. +value based on all of a application’s reviews and/or review preferences. For instance, “max(OveMer)” would return the maximum Overall merit score -assigned to a paper.

    +assigned to a application.

    An aggregate function’s argument is calculated once per viewable review or preference. diff --git a/src/help/h_ranking.php b/src/help/h_ranking.php index 8140ab5dc..207b8930e 100644 --- a/src/help/h_ranking.php +++ b/src/help/h_ranking.php @@ -4,24 +4,24 @@ class Ranking_HelpTopic { static function print(HelpRenderer $hth) { - echo "

    Paper ranking is a way to extract the PC’s preference order for -submitted papers. Each PC member ranks the submitted papers, and a voting + echo "

    Application ranking is a way to extract the PC’s preference order for +submitted applications. Each PC member ranks the submitted applications, and a voting algorithm, the Schulze method by default, combines these rankings into a global preference order.

    HotCRP supports ranking through ", $hth->help_link("tags", "tags"), ". The chair chooses a tag for ranking—“rank” is a good default—and enters it on ", $hth->setting_link("the settings page", "tag_rank"), ". -PC members then rank papers using their private versions of this tag, +PC members then rank applications using their private versions of this tag, tagging their first preference with “~rank#1”, their second preference with “~rank#2”, and so forth. To combine PC rankings into a global preference order, the PC -chair selects all papers on ", $hth->search_link("the search page", ""), +chair selects all applications on ", $hth->search_link("the search page", ""), " and chooses Tags > Calculate rank, entering “rank” for the tag. At that point, the global rank can be viewed by ", $hth->search_link("searching for “order:rank”", "order:rank"), ".

    -

    PC members can enter rankings by reordering rows in a paper list. +

    PC members can enter rankings by reordering rows in a application list. For example, for rank tag “rank”, PC members should ", $hth->search_link("search for “editsort:#~rank”", "editsort:#~rank"), ". Ranks can be entered directly in the text fields, or the rows can be dragged @@ -36,12 +36,12 @@ static function print(HelpRenderer $hth) { # Edit the rank order by rearranging this file's lines. # The first line has the highest rank. -# Lines that start with \"#\" are ignored. Unranked papers appear at the end +# Lines that start with \"#\" are ignored. Unranked applications appear at the end # in lines starting with \"X\", sorted by overall merit. Create a rank by # removing the \"X\"s and rearranging the lines. A line that starts with \"=\" -# marks a paper with the same rank as the preceding paper. A line that starts +# marks a application with the same rank as the preceding application. A line that starts # with \">>\", \">>>\", and so forth indicates a rank gap between the preceding -# paper and the current paper. When you are done, upload the file at +# application and the current application. When you are done, upload the file at # http://your.site.here.com/offline Tag: ~rank diff --git a/src/help/h_search.php b/src/help/h_search.php index f323b7397..15004717c 100644 --- a/src/help/h_search.php +++ b/src/help/h_search.php @@ -13,9 +13,9 @@ static function print(HelpRenderer $hth) { quicksearch box, this search will jump to #12 directly.

  • ", $hth->help_link("Search keywords", "keywords"), " let you search specific fields, review scores, and more.
    • -
  • Use quicklinks on paper pages to navigate +
  • Use quicklinks on application pages to navigate through search results. Typing j and k also goes - from paper to paper.
    • + from application to application.
  • On list pages, shift-click checkboxes to select ranges of submissions.
    • "; @@ -56,32 +56,32 @@ static function print(HelpRenderer $hth) { echo $hth->subhead("Search results"); echo " -

    Click on a paper number or title to jump to that paper. -Search matches are highlighted on paper screens. -Once on a paper screen use quicklinks +

    Click on a application number or title to jump to that application. +Search matches are highlighted on application screens. +Once on a application screen use quicklinks to navigate through the rest of the search matches.

    -

    Underneath the paper list is the action area:

    +

    Underneath the application list is the action area:

    " . Ht::img("exsearchaction.png", "[Search action area]") . "
    -

    Use the checkboxes to select some papers, then choose an action. +

    Use the checkboxes to select some applications, then choose an action. You can:

      -
    • Download a .zip file with the selected papers.
      • -
    • Download all reviews for the selected papers.
      • +
    • Download a .zip file with the selected applications.
      • +
    • Download all reviews for the selected applications.
    • Download tab-separated text files with authors, PC conflicts, review scores, and so forth (some options chairs only).
    • Add, remove, and define ", $hth->help_link("tags", "tags"), ".
    • Assign reviewers and mark conflicts (chairs only).
    • Set decisions (chairs only).
      • -
    • Send mail to paper authors or reviewers (chairs only).
      • +
    • Send mail to application authors or reviewers (chairs only).
    -

    Select papers one by one, select in groups by shift-clicking +

    Select applications one by one, select in groups by shift-clicking the checkboxes, or use the “select all” link. -The easiest way to tag a set of papers is +The easiest way to tag a set of applications is to enter their numbers in the search box, search, “select all,” and add the tag.

    "; @@ -90,13 +90,13 @@ static function print(HelpRenderer $hth) {

    Most screens have a quicksearch box in the upper right corner:
    " . Ht::img("quicksearchex.png", "[Quicksearch box]") . "
    This box supports the full search syntax. Enter -a paper number, or search terms that match exactly -one paper, to go directly to that paper.

    +a application number, or search terms that match exactly +one application, to go directly to that application.

    -

    Paper screens have quicklinks that step through search results:
    +

    Application screens have quicklinks that step through search results:
    " . Ht::img("pageresultsex.png", "[Quicklinks]") . "
    -Click on the search description (here, “Submitted papers search”) to return +Click on the search description (here, “Submitted applications search”) to return to the search results. On many pages, you can press “j” or -“k” to go to the previous or next paper in the list.

    "; +“k” to go to the previous or next application in the list.

    "; } } diff --git a/src/help/h_tags.php b/src/help/h_tags.php index 8bd1e5425..361494bbe 100644 --- a/src/help/h_tags.php +++ b/src/help/h_tags.php @@ -22,10 +22,10 @@ function print_intro() { $conflictmsg = " and conflicted PC members"; } - echo "

    PC members and administrators can attach tag names to papers. -It’s easy to change tags and to list all papers with a given tag, -and ordered tags preserve a particular paper order. -Tags also affect color highlighting in paper lists.

    + echo "

    PC members and administrators can attach tag names to applications. +It’s easy to change tags and to list all applications with a given tag, +and ordered tags preserve a particular application order. +Tags also affect color highlighting in application lists.

    Tags are visible to the PC and hidden from authors$conflictmsg. Twiddle tags, with names like “#~tag”, are visible only to their creators. Tags @@ -36,7 +36,7 @@ function print_intro() { function print_finding() { $hth = $this->hth; echo $hth->subhead("Find tags", "find"); - echo "

    A paper’s tags are shown like this on the paper page:

    + echo "

    A application’s tags are shown like this on the applications page:

    ", @@ -51,18 +51,18 @@ function print_finding() { '
    ', "
    -

    To find all papers with tag “#discuss”:

    +

    To find all applications with tag “#discuss”:

    ", $hth->search_form("#discuss"), "

    You can also search with “", $hth->search_link("show:tags"), "” to see each -paper’s tags, or “", $hth->search_link("show:#tagname"), "” to see a particular tag +application’s tags, or “", $hth->search_link("show:#tagname"), "” to see a particular tag as a column.

    Tags are only shown to PC members and administrators. "; if ($this->user->isPC) { if ($this->conf->tag_seeall) { - echo "Currently PC members can see tags for any paper, including conflicts."; + echo "Currently PC members can see tags for any application, including conflicts."; } else { echo "They are hidden from conflicted PC members; for instance, if a PC member searches for a tag, the result will never include their conflicts."; } @@ -76,14 +76,14 @@ function print_changing() { echo $hth->subhead("Change tags", "change"); echo "

      -

    • For one paper: Go to a paper page, click the +

    • For one application: Go to a application page, click the “", expander(true), "Tags” expander, and enter tags separated by spaces.

      • -

    • For many papers: ", $hth->hotlink("Search", "search"), -" for papers, select them, and use the action area underneath the -search list. Add adds tags to the selected papers, Remove removes -tags from the selected papers, and Define adds the tag to the selected -papers and removes it from all others.

      +

    • For many applications: ", $hth->hotlink("Search", "search"), +" for applications, select them, and use the action area underneath the +search list. Add adds tags to the selected applications, Remove removes +tags from the selected applications, and Define adds the tag to the selected +applications and removes it from all others.

      ", Ht::img("extagssearch.png", "[Setting tags on the search page]", ["width" => 510, "height" => 94]), "

      • @@ -91,7 +91,7 @@ function print_changing() { $hth->search_link("edit:tag:tagname"), "” to add tags with checkboxes; search for “", $hth->search_link("edit:tagval:tagname"), "” to type in tag values; or search for “", $hth->search_link("edit:tags"), "” -to edit papers’ full tag lists.

      +to edit applications’ full tag lists.

      ", Ht::img("extagseditkw.png", "[Tag editing search keywords]", ["width" => 543, "height" => 133]), "

      @@ -114,31 +114,31 @@ function print_values() { specific values with search terms like “", $hth->search_link("#discuss#2"), "” or “", $hth->search_link("#discuss>1"), "”. A search like “", $hth->search_link("order:#tagname"), "” selects -papers with the named tag and displays them ordered by that tag’s values.

      +applications with the named tag and displays them ordered by that tag’s values.

      -

      It’s common to assign increasing tag values to a set of papers. Do this +

      It’s common to assign increasing tag values to a set of applications. Do this using the ", $hth->hotlink("search screen", "search"), ". Search for the -papers you want, sort them into the right order, select their checkboxes, and +applications you want, sort them into the right order, select their checkboxes, and choose Define order in the tag action area. If no sort gives what -you want, search for the desired paper numbers in order—for instance, +you want, search for the desired application numbers in order—for instance, “", $hth->search_link("4 1 12 9"), "”—then Select all and Define order.

      Define order might assign values “#tag#1”, “#tag#3”, “#tag#6”, and “#tag#7” -to adjacent papers. The gaps make it harder to infer -conflicted papers’ positions. (Any given gap might or might not hold a -conflicted paper.) The Define gapless order action assigns +to adjacent applications. The gaps make it harder to infer +conflicted applications’ positions. (Any given gap might or might not hold a +conflicted application.) The Define gapless order action assigns strictly sequential values, like “#tag#1”, “#tag#2”, “#tag#3”, “#tag#4”. Define order is better for most purposes.

      -

      To add new papers at the end of an existing discussion order, use Add to +

      To add new applications at the end of an existing discussion order, use Add to order. To create an order by entering explicit positions and/or dragging -papers into order, use a search like “", $hth->search_link("editsort:#tagname"), "”.

      +applications into order, use a search like “", $hth->search_link("editsort:#tagname"), "”.

      The ", $hth->hotlink("autoassigner", "autoassign", "a=discorder"), " -has special support for creating discussion orders. It tries to group papers +has special support for creating discussion orders. It tries to group applications with similar PC conflicts, which can make the meeting run smoother.

      "; } @@ -146,12 +146,12 @@ function print_colors() { $hth = $this->hth; echo $hth->subhead("Colors", "colors"); echo "

      Tags “red”, “orange”, “yellow”, “green”, “blue”, “purple”, “gray”, and -“white” act as highlight colors. For example, papers tagged with “#red” will -appear red in paper lists (for people -who can see that tag). Tag a paper “#~red” to make it red only on your display. +“white” act as highlight colors. For example, applications tagged with “#red” will +appear red in application lists (for people +who can see that tag). Tag a application “#~red” to make it red only on your display. Other styles are available; try “#bold”, “#italic”, “#big”, “#small”, and “#dim”. The ", $hth->setting_link("settings page", "tag_style"), " can associate other tags -with colors so that, for example, “" . $hth->search_link("#reject") . "” papers appear +with colors so that, for example, “" . $hth->search_link("#reject") . "” applications appear gray.

      \n"; } @@ -165,53 +165,53 @@ function print_example_r1reject() { echo "

      Skip low-ranked submissions. Mark low-ranked submissions with tag “#r1reject”, then ask the PC to " . $this->hth->search_link("search for “#r1reject”", "#r1reject") . ". PC members -can check the list for papers they’d like to discuss anyway. They can email -the chairs about such papers, or remove the tag themselves. (You might make +can check the list for applications they’d like to discuss anyway. They can email +the chairs about such applications, or remove the tag themselves. (You might make the “#r1reject” tag chair-only so an evil PC member couldn’t add it to a -high-ranked paper, but it’s usually better to trust the PC.)

      \n"; +high-ranked application, but it’s usually better to trust the PC.)

      \n"; } function print_example_controversial() { - echo "

      Mark controversial papers that would benefit from additional review. + echo "

      Mark controversial applications that would benefit from additional review. PC members could add the “#controversial” tag when the current reviewers disagree. A ", $this->hth->hotlink("search", "search", ["q" => "#controversial"]), " shows where the PC thinks more review is needed.

      \n"; } function print_example_pcpaper() { - echo "

      Mark PC-authored papers for extra scrutiny. + echo "

      Mark PC-authored applications for extra scrutiny. First, ", $this->hth->hotlink("search for PC members’ last names in author fields", "search", "t=s&qt=au"), ". - Check for accidental matches and select the papers with PC members as authors, then use the action area below the search list to add the tag “#pcpaper”. - A ", $this->hth->hotlink("search", "search", "t=s&q=-%23pcpaper"), " shows papers without PC authors.

      \n"; + Check for accidental matches and select the applications with PC members as authors, then use the action area below the search list to add the tag “#pcpaper”. + A ", $this->hth->hotlink("search", "search", "t=s&q=-%23pcpaper"), " shows applications without PC authors.

      \n"; } function print_example_allotment() { $vt = $this->hth->example_tag("allotment"); - echo "

      Vote for papers. + echo "

      Vote for applications. The chair can define tags used for allotment voting", $this->hth->current_tag_list("allotment"), ".", $this->hth->change_setting_link("tag_vote_allotment"), - " Each PC member is assigned an allotment of votes to distribute among papers. - For instance, if “#{$vt}” were a voting tag with an allotment of 10, then a PC member could assign 5 votes to a paper by adding the twiddle tag “#~{$vt}#5”. + " Each PC member is assigned an allotment of votes to distribute among applications. + For instance, if “#{$vt}” were a voting tag with an allotment of 10, then a PC member could assign 5 votes to a application by adding the twiddle tag “#~{$vt}#5”. The system automatically sums PC members’ votes into the public “#{$vt}” tag. - To search for papers by vote count, search for “", $this->hth->search_link("rorder:#$vt"), + To search for applications by vote count, search for “", $this->hth->search_link("rorder:#$vt"), "”. (", $this->hth->help_link("votetags"), ")

      \n"; } function print_example_rank() { - echo "

      Rank papers. - Each PC member can set tags indicating their preference ranking for papers. - For instance, a PC member’s favorite paper would get tag “#~rank#1”, the next favorite “#~rank#2”, and so forth. + echo "

      Rank applications. + Each PC member can set tags indicating their preference ranking for applications. + For instance, a PC member’s favorite application would get tag “#~rank#1”, the next favorite “#~rank#2”, and so forth. The chair can then combine these rankings into a global preference order using a Condorcet method. (", $this->hth->help_link("ranking"), ")

      \n"; } function print_example_discuss() { echo "

      Define a discussion order. -Publishing the order lets PC members prepare to discuss upcoming papers. +Publishing the order lets PC members prepare to discuss upcoming applications. Define an ordered tag such as “#discuss”, then ask the PC to ", $this->hth->search_link("search for “order:#discuss”", "order:#discuss"), ". -The PC can now see the order and use quick links to go from paper to paper."; +The PC can now see the order and use quick links to go from application to application."; if ($this->user->isPC && !$this->conf->tag_seeall) { - echo " However, since PC members can’t see tags for conflicted papers, each PC member might see a different list.", $this->hth->change_setting_link("tag_visibility_conflict"); + echo " However, since PC members can’t see tags for conflicted applications, each PC member might see a different list.", $this->hth->change_setting_link("tag_visibility_conflict"); } echo "

      \n"; } diff --git a/src/help/h_votetags.php b/src/help/h_votetags.php index d64276890..81371d7fd 100644 --- a/src/help/h_votetags.php +++ b/src/help/h_votetags.php @@ -5,12 +5,12 @@ class VoteTags_HelpTopic { static function print(HelpRenderer $hth) { $votetag = $hth->example_tag("allotment"); - echo "

      Some conferences have PC members vote for papers. In + echo "

      Some conferences have PC members vote for applications. In allotment voting, each PC member is assigned a vote allotment to -distribute among unconflicted papers; a PC member might assign one vote to one +distribute among unconflicted applications; a PC member might assign one vote to one submission and five to another. In approval voting, each PC member -can vote for as many papers as they like. The PC’s aggregated vote totals -might help determine which papers to discuss.

      +can vote for as many applications as they like. The PC’s aggregated vote totals +might help determine which applications to discuss.

      HotCRP supports voting through ", $hth->help_link("tags", "tags"), ". The chair can ", $hth->setting_link("define a set of voting tags", "tag_vote_allotment"), @@ -27,9 +27,9 @@ static function print(HelpRenderer $hth) { updates the main “#vote” tag to reflect the total. (An error is reported when PC members exceed their allotment.)

      -

      To see papers’ vote counts in a list, search for ", +

      To see applications’ vote counts in a list, search for ", $hth->search_link("show:#$votetag"), -". To list the papers with votes, sorted by vote count (most votes first), +". To list the applications with votes, sorted by vote count (most votes first), search for ", $hth->search_link("rorder:#$votetag"), " or ", $hth->search_link("rorder:#$votetag show:#$votetag"), ".

      diff --git a/src/listaction.php b/src/listaction.php index ab291203f..e0ff55e76 100644 --- a/src/listaction.php +++ b/src/listaction.php @@ -98,7 +98,7 @@ static private function do_call($name, Contact $user, Qrequest $qreq, $selection if (!$uf || !Conf::xt_resolve_require($uf) || !is_string($uf->function)) { return JsonResult::make_error(404, "<0>Action not found"); } else if (($uf->paper ?? false) && $selection->is_empty()) { - return JsonResult::make_error(400, "<0>No papers selected"); + return JsonResult::make_error(400, "<0>No applications selected"); } else if ($uf->function[0] === "+") { $class = substr($uf->function, 1); /** @phan-suppress-next-line PhanTypeExpectedObjectOrClassName */ @@ -150,7 +150,7 @@ static function pcassignments_csv_data(Contact $user, $pids) { $texts[] = []; $texts[] = ["paper" => $prow->paperId, "action" => "none", - "title" => "You cannot override your conflict with this paper"]; + "title" => "You cannot override your conflict with this application"]; } else { $any_this_paper = false; foreach ($prow->reviews_as_display() as $rrow) { diff --git a/src/mailrecipients.php b/src/mailrecipients.php index c0e886a4a..373291ffd 100644 --- a/src/mailrecipients.php +++ b/src/mailrecipients.php @@ -144,8 +144,8 @@ private function enumerate_recipients() { if ($user->is_manager()) { $this->recipt_default_message = "authors"; $hide = !$this->conf->has_any_submitted(); - $this->defsel("s", "Contact authors of submitted papers", $hide ? self::F_HIDE : 0); - $this->defsel("unsub", "Contact authors of unsubmitted papers"); + $this->defsel("s", "Contact authors of submitted applications", $hide ? self::F_HIDE : 0); + $this->defsel("unsub", "Contact authors of unsubmitted applications"); $this->defsel("au", "All contact authors"); $this->dcounts(); @@ -156,10 +156,10 @@ private function enumerate_recipients() { $this->defsel("dec:{$dec->name}", "Contact authors of " . $dec->name_as(5) . " papers", $hide ? self::F_HIDE : 0); } } - $this->defsel("dec:yes", "Contact authors of accept-class papers", $this->_has_dt[2] ? 0 : self::F_HIDE); - $this->defsel("dec:no", "Contact authors of reject-class papers", $this->_has_dt[0] ? 0 : self::F_HIDE); - $this->defsel("dec:none", "Contact authors of undecided papers", $this->_has_dt[1] && ($this->_has_dt[0] || $this->_has_dt[2]) ? 0 : self::F_HIDE); - $this->defsel("dec:any", "Contact authors of decided papers", self::F_HIDE); + $this->defsel("dec:yes", "Contact authors of accept-class applications", $this->_has_dt[2] ? 0 : self::F_HIDE); + $this->defsel("dec:no", "Contact authors of reject-class applications", $this->_has_dt[0] ? 0 : self::F_HIDE); + $this->defsel("dec:none", "Contact authors of undecided applications", $this->_has_dt[1] && ($this->_has_dt[0] || $this->_has_dt[2]) ? 0 : self::F_HIDE); + $this->defsel("dec:any", "Contact authors of decided applications", self::F_HIDE); $this->defsel("bydec_group_end", null, self::F_GROUP); $this->recipt_default_message = "reviewers"; diff --git a/src/pages/p_adminhome.php b/src/pages/p_adminhome.php index d51aadd17..e8e15da4e 100644 --- a/src/pages/p_adminhome.php +++ b/src/pages/p_adminhome.php @@ -31,7 +31,7 @@ static function print(Contact $user) { if (($row = $result->fetch_row()) && $row[1] < $max_file_size && !$conf->opt("dbNoPapers")) { - $ml[] = new MessageItem(null, "<5>MySQL’s max_allowed_packet setting, which is " . htmlspecialchars($row[1]) . " bytes, is less than the PHP upload file limit, which is {$max_file_size} bytes. You should update max_allowed_packet in the system-wide my.cnf file or the system may not be able to handle large papers", MessageSet::URGENT_NOTE); + $ml[] = new MessageItem(null, "<5>MySQL’s max_allowed_packet setting, which is " . htmlspecialchars($row[1]) . " bytes, is less than the PHP upload file limit, which is {$max_file_size} bytes. You should update max_allowed_packet in the system-wide my.cnf file or the system may not be able to handle large applications", MessageSet::URGENT_NOTE); } if ($max_file_size < ini_get_bytes(null, "10M") && $max_file_size < $conf->upload_max_filesize()) { @@ -81,7 +81,7 @@ static function print(Contact $user) { // Any -100 preferences around? $result = PrefConflict_Autoassigner::query_result($conf, true); if (($row = $result->fetch_row())) { - $ml[] = new MessageItem(null, '<5>PC members have indicated paper conflicts (using review preferences of −100 or less) that aren’t yet confirmed. Confirm these conflicts', MessageSet::MARKED_NOTE); + $ml[] = new MessageItem(null, '<5>PC members have indicated application conflicts (using review preferences of −100 or less) that aren’t yet confirmed. Confirm these conflicts', MessageSet::MARKED_NOTE); } // Weird URLs? foreach (["conferenceSite", "paperSite"] as $k) { diff --git a/src/pages/p_autoassign.php b/src/pages/p_autoassign.php index f9221cdcd..2814ff417 100644 --- a/src/pages/p_autoassign.php +++ b/src/pages/p_autoassign.php @@ -200,9 +200,9 @@ private function print_review_actions() { ["size" => 3, "class" => $this->ms->control_class("review:count", "js-autosubmit")]), "  additional  ", Ht::select("review:rtype", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview"], $qreq["review:type"]), - "  review(s) per selected paper\n"; + "  review(s) per selected application\n"; - $this->print_radio_row("a", "review_ensure", "Ensure each selected paper has at least", ["open" => true]); + $this->print_radio_row("a", "review_ensure", "Ensure each selected application has at least", ["open" => true]); echo "  ", Ht::entry("review_ensure:count", $qreq["review_ensure:count"] ?? 1, ["size" => 3, "class" => $this->ms->control_class("review_ensure:count", "js-autosubmit")]), "  ", @@ -215,7 +215,7 @@ private function print_review_actions() { ["size" => 3, "class" => $this->ms->control_class("review_per_pc:count", "js-autosubmit")]), "  additional  ", Ht::select("review_per_pc:rtype", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview"], $qreq["review_per_pc:rtype"]), - "  review(s) from this paper selection"; + "  review(s) from this application selection"; // Review round $rev_rounds = $this->conf->round_selector_options(null); @@ -243,7 +243,7 @@ private function print_conflict_actions() { $this->print_radio_row("a", "prefconflict", "Assign conflicts when PC members have review preferences of −100 or less"); $this->print_radio_row("a", "clear", "Clear all  ", ["open" => true]); echo Ht::select("clear:type", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview", "conflict" => "conflict", "lead" => "discussion lead", "shepherd" => "shepherd"], $this->qreq["clear:type"]), - "  assignments for selected papers and PC members\n"; + "  assignments for selected applications and PC members\n"; } private function print_lead_actions() { @@ -261,7 +261,7 @@ private function print_discussion_actions() { $this->print_radio_row("a", "discussion_order", "Create discussion order in tag #", ["open" => true]); echo Ht::entry("discussion_order:tag", $this->qreq["discussion_order:tag"] ?? "discuss", ["size" => 12, "class" => $this->ms->control_class("discussion_order:tag", "js-autosubmit")]), - ", grouping papers with similar PC conflicts"; + ", grouping applications with similar PC conflicts"; } private function bp_selector($i, $which) { @@ -284,7 +284,7 @@ private function print_bad_pairs() { echo '', $this->bp_selector($i, "a"), "  and  ", $this->bp_selector($i, "b"); if ($i == 1) { - echo '  to the same paper  (  ·  )'; + echo '  to the same application  (  ·  )'; } echo "\n"; } @@ -332,7 +332,7 @@ private function print() { Assignment methods: @@ -348,7 +348,7 @@ private function print() { // paper selection echo '
      ', - '

      Paper selection

      ', + '

      Application selection

      ', Ht::entry("q", $qreq->q, [ "id" => "autoassignq", "placeholder" => "(All)", "size" => 40, "aria-label" => "Search", @@ -363,7 +363,7 @@ private function print() { $plist = new PaperList("reviewersSel", $search); $plist->set_selection($this->ssel)->set_table_decor(PaperList::DECOR_HEADER); if ($search->paper_ids()) { - echo "
      Assignments will apply to the selected papers."; + echo "
      Assignments will apply to the selected applications."; } echo '
      '; $plist->print_table_html(); diff --git a/src/pages/p_bulkassign.php b/src/pages/p_bulkassign.php index 769071334..153d55120 100644 --- a/src/pages/p_bulkassign.php +++ b/src/pages/p_bulkassign.php @@ -158,11 +158,11 @@ function print_instructions() { BulkAssign_HelpTopic::print_actions($this->user); - echo "

      For example, this file clears existing R1 review assignments for papers + echo "

      For example, this file clears existing R1 review assignments for applications tagged #redo, then assigns two primary reviews for submission #1 and one secondary review for submission #2:

      -
      paper,action,email,round
+
      application,action,email,round
 #redo,clearreview,all,R1
 1,primary,man@alice.org
 2,secondary,slugger@manny.com
@@ -231,7 +231,7 @@ function print() {
 Assignment methods:
 
diff --git a/src/pages/p_home.php b/src/pages/p_home.php
index aef010ed2..18b3e2a4f 100644
--- a/src/pages/p_home.php
+++ b/src/pages/p_home.php
@@ -170,7 +170,7 @@ static function print_info_accepted(Contact $user) {
         assert($user->conf->time_all_author_view_decision());
         if ($user->conf->time_all_author_view_decision()) {
             list($n, $nyes) = $user->conf->count_submitted_accepted();
-            echo '
    • ', $user->conf->_("%d papers accepted out of %d submitted.", $nyes, $n), '
      • ';
+            echo '
    • ', $user->conf->_("%d applications accepted out of %d submitted.", $nyes, $n), '
      • ';
         }
     }
 
@@ -210,7 +210,7 @@ function print_search(Contact $user, Qrequest $qreq, $gx) {
             Ht::form($this->conf->hoturl("search"), ["method" => "get", "class" => "form-basic-search"]),
             Ht::entry("q", (string) $qreq->q, [
                 "id" => "homeq", "size" => 32,
-                "title" => "Enter paper numbers or search terms",
+                "title" => "Enter application numbers or search terms",
                 "class" => "papersearch need-suggest flex-grow-1 mb-1",
                 "placeholder" => "(All)",
                 "aria-labelledby" => "homesearch-label",
@@ -376,9 +376,9 @@ function print_reviews(Contact $user, Qrequest $qreq, $gx) {
             }
         }
         if ($user->isPC && $user->can_review_any()) {
-            echo '  As a PC member, you may review any submitted paper.
      \n";
+            echo '  As a PC member, you may review any submitted application.
      \n";
         } else if ($user->privChair) {
-            echo '  As an administrator, you may review any submitted paper.
      \n";
+            echo '  As an administrator, you may review any submitted application.
      \n";
         }
 
         if ($has_rinfo) {
@@ -625,7 +625,7 @@ function print_submissions(Contact $user, Qrequest $qreq, $gx) {
             if ($conf->time_after_setting("final_soft") && $plist->has("need_final")) {
                 $deadlines[] = "Final versions are overdue. They were requested by {$d}.";
             } else if ($d) {
-                $deadlines[] = "Submit final versions of your accepted papers by {$d}.";
+                $deadlines[] = "Submit final versions of your accepted applications by {$d}.";
             }
         }
         if (!empty($deadlines)) {
diff --git a/src/pages/p_log.php b/src/pages/p_log.php
index a052730fd..4e4c2bcbd 100644
--- a/src/pages/p_log.php
+++ b/src/pages/p_log.php
@@ -56,14 +56,14 @@ private function add_search_clause($query, $field) {
             $w = [];
             foreach ($pids as $p) {
                 $w[] = "paperId={$p}";
-                $w[] = "action like '%(papers% {$p},%'";
-                $w[] = "action like '%(papers% {$p})%'";
+                $w[] = "action like '%(applications% {$p},%'";
+                $w[] = "action like '%(applications% {$p})%'";
             }
             $this->lef_clauses[] = "(" . join(" or ", $w) . ")";
             $this->include_pids = array_flip($pids);
         } else {
             if (!$search->has_problem()) {
-                $this->ms->warning_at($field, "No papers match that search.");
+                $this->ms->warning_at($field, "No applications match that search.");
             }
             $this->lef_clauses[] = "false";
         }
@@ -200,7 +200,7 @@ function handle_download($leg) {
         if ($narrow) {
             $headers[] = "roles";
         }
-        array_push($headers, "affected_email", "via", $narrow ? "paper" : "papers", "action");
+        array_push($headers, "affected_email", "via", $narrow ? "application" : "applications", "action");
         $csvg->select($headers);
         foreach ($leg->page_rows(1) as $row) {
             $date = date("Y-m-d H:i:s O", (int) $row->timestamp);
@@ -284,7 +284,7 @@ function print_searchbar(LogEntryGenerator $leg, $page) {
             $this->ms->feedback_html_at("q"),
             Ht::entry("q", $this->qreq->q, ["id" => "q", "size" => 40]),
             '
      ', + '">
      ', $this->ms->feedback_html_at("p"), Ht::entry("p", $this->qreq->p, ["id" => "p", "class" => "need-suggest papersearch", "size" => 40, "spellcheck" => false]), '
      viewer->privChair || !empty($this->exclude_pids)) { echo '
      '; if (!$this->viewer->privChair) { - $conf->feedback_msg(new MessageItem(null, "<0>Only showing your actions, plus entries for papers you administer", MessageSet::MARKED_NOTE)); + $conf->feedback_msg(new MessageItem(null, "<0>Only showing your actions, plus entries for applications you administer", MessageSet::MARKED_NOTE)); } else if (!empty($this->exclude_pids) && (!$this->include_pids || array_intersect_key($this->include_pids, $this->exclude_pids)) && array_keys($this->exclude_pids) != array_keys($this->viewer->hidden_papers ? : [])) { @@ -469,7 +469,7 @@ function print_page($leg, $page) { if ($this->qreq->forceShow) { // XXX never true $conf->feedback_msg(new MessageItem(null, "<5>Showing all entries (" . Ht::link("unprivileged view", $conf->selfurl($this->qreq, $req + ["forceShow" => null])) . ")", MessageSet::MARKED_NOTE)); } else { - $conf->feedback_msg(new MessageItem(null, "<5>Not showing entries for " . Ht::link("conflicted administered papers", $conf->hoturl("search", "q=" . join("+", array_keys($this->exclude_pids)))), MessageSet::MARKED_NOTE)); + $conf->feedback_msg(new MessageItem(null, "<5>Not showing entries for " . Ht::link("conflicted administered applications", $conf->hoturl("search", "q=" . join("+", array_keys($this->exclude_pids)))), MessageSet::MARKED_NOTE)); } } echo '
      '; @@ -542,11 +542,11 @@ private function print_entry($row, $n, $leg) { $act = $m[4]; } else if (substr($act, 0, 7) === "Comment" && preg_match('/\AComment (\d+)(.*)\z/s', $act, $m)) { - $at = "hoturl("paper", "p={$row->paperId}#cid{$m[1]}") . "\">Comment " . $m[1] . ""; + $at = "hoturl("application", "p={$row->paperId}#cid{$m[1]}") . "\">Comment " . $m[1] . ""; $act = $m[2]; } else if (substr($act, 0, 8) === "Response" && preg_match('/\AResponse (\d+)(.*)\z/s', $act, $m)) { - $at = "hoturl("paper", "p={$row->paperId}#cid{$m[1]}") . "\">Response " . $m[1] . ""; + $at = "hoturl("application", "p={$row->paperId}#cid{$m[1]}") . "\">Response " . $m[1] . ""; $act = $m[2]; } else if (strpos($act, " mail ") !== false && preg_match('/\A(Sending|Sent|Account was sent) mail #(\d+)(.*)\z/s', $act, $m)) { @@ -566,7 +566,7 @@ private function print_entry($row, $n, $leg) { . '' . substr($word, $hash); } } else if ($row->paperId > 0 - && str_starts_with($act, "Paper ") + && str_starts_with($act, "Application ") && ($colon = strpos($act, ":")) !== false && $this->document_regexp !== "") { $at = substr($act, 0, $colon); @@ -581,11 +581,11 @@ private function print_entry($row, $n, $leg) { $at .= htmlspecialchars($act); if (($pids = $leg->paper_ids($row))) { if (count($pids) === 1) - $at .= ' (paper ' . $pids[0] . ")"; + $at .= ' (application ' . $pids[0] . ")"; else { - $at .= ' (papers'; + $at .= ' (applications'; foreach ($pids as $i => $p) { - $at .= ($i ? ', ' : ' ') . '' . $p . ''; + $at .= ($i ? ', ' : ' ') . '' . $p . ''; } $at .= ')'; } diff --git a/src/pages/p_mail.php b/src/pages/p_mail.php index 39973b05d..0be612f9c 100644 --- a/src/pages/p_mail.php +++ b/src/pages/p_mail.php @@ -144,7 +144,7 @@ private function request() { && $this->recip->has_paper_ids() && empty($this->recip->paper_ids()) && !isset($this->qreq->recheck)) { - $this->recip->error_at("q", "<0>No papers match that search"); + $this->recip->error_at("q", "<0>No applications match that search"); $this->recip->set_paper_ids(null); unset($this->qreq->check, $this->qreq->send); } @@ -180,9 +180,9 @@ function print_keyword_help() {
      %URL%
      Site URL.
      %NUMSUBMITTED%
      -
      Number of papers submitted.
      +
      Number of applications submitted.
      %NUMACCEPTED%
      -
      Number of papers accepted.
      +
      Number of applications accepted.
      %NAME%
      Full name of recipient.
      %FIRST%, %LAST%
      @@ -193,13 +193,13 @@ function print_keyword_help() {
      Reviewing deadline appropriate for recipient.
    %NUMBER%
    -
    Paper number relevant for mail.
    +
    Application number relevant for mail.
    %TITLE%
    -
    Paper title.
    +
    Application title.
    %TITLEHINT%
    -
    First couple words of paper title (useful for mail subject).
    +
    First couple words of application title (useful for mail subject).
    %OPT(AUTHORS)%
    -
    Paper authors (if recipient is allowed to see the authors).
    +
    Application authors (if recipient is allowed to see the authors).
    '; $opts = array_filter($this->conf->options()->normal(), function ($o) { @@ -215,20 +215,20 @@ function print_keyword_help() { }); if (!empty($opts)) { echo '
    %', htmlspecialchars($opts[0]->search_keyword()), '%
    -
    Value of paper’s “', $opts[0]->title_html(), '” submission field.'; +
    Value of application’s “', $opts[0]->title_html(), '” submission field.'; if (count($opts) > 1) { echo ' Also ', join(", ", array_map(function ($o) { return '%' . htmlspecialchars($o->search_keyword()) . '%'; }, array_slice($opts, 1))), '.'; } echo "
    \n
    %IF(", htmlspecialchars($opts[0]->search_keyword()), ')%...%ENDIF%
    -
    Include text if paper has a “', $opts[0]->title_html(), "” submission field.
    \n"; +
    Include text if application has a “', $opts[0]->title_html(), "” submission field.
    \n"; } echo '
    %REVIEWS%
    -
    Pretty-printed paper reviews.
    +
    Pretty-printed application reviews.
    %COMMENTS%
    -
    Pretty-printed paper comments, if any.
    +
    Pretty-printed application comments, if any.
    %COMMENTS(tag)%
    Comments tagged #tag, if any.
    @@ -242,9 +242,9 @@ function print_keyword_help() {
    Shepherd email, if any.
    %IF(#tag)%...%ENDIF%
    -
    Include text if paper has tag tag.
    +
    Include text if application has tag tag.
    %TAGVALUE(tag)%
    -
    Value of paper’s tag.
    +
    Value of application’s tag.
    '; } @@ -287,7 +287,7 @@ private function print_paper_selection() { Ht::hidden("has_plimit", 1), Ht::checkbox("plimit", 1, !!$this->qreq->plimit, ["id" => "plimit", "class" => "uich js-mail-recipients"]), '', - ''; + ''; } else { echo '
    ', Ht::hidden("has_plimit", 1), @@ -301,12 +301,12 @@ private function print_paper_selection() { $this->recip->append_item_at("q", $mi); } if ($plist->is_empty()) { - $this->recip->warning_at("q", "<0>No papers match that search."); + $this->recip->warning_at("q", "<0>No applications match that search."); } } echo '
    '; if (!$this->viewer->privChair) { - echo ''; + echo ''; } echo Ht::entry("q", (string) $this->qreq->q, [ "placeholder" => "(All)", "spellcheck" => false, diff --git a/src/pages/p_offline.php b/src/pages/p_offline.php index 8e4b02816..1cf9da913 100644 --- a/src/pages/p_offline.php +++ b/src/pages/p_offline.php @@ -118,7 +118,7 @@ function print() { } echo '
  • Blank form
    • ', ' -
    Tip: Use Search > Download to choose individual papers.
    ', +
    Tip: Use Search > Download to choose individual applications.
    ', ""; $pastDeadline = !$conf->time_review(null, $this->user->isPC, true); @@ -143,7 +143,7 @@ function print() { '', "\n"; diff --git a/src/pages/p_paper.php b/src/pages/p_paper.php index 6b25ae07b..5dd05c835 100644 --- a/src/pages/p_paper.php +++ b/src/pages/p_paper.php @@ -84,7 +84,7 @@ function handle_withdraw() { $aset = new AssignmentSet($this->user); $aset->override_conflicts(); $aset->enable_papers($this->prow); - $aset->parse("paper,action,withdraw reason\n{$this->prow->paperId},withdraw," . CsvGenerator::quote($reason)); + $aset->parse("application,action,withdraw reason\n{$this->prow->paperId},withdraw," . CsvGenerator::quote($reason)); if (!$aset->execute()) { error_log("{$this->conf->dbname}: withdraw #{$this->prow->paperId} failure: " . json_encode($aset->json_result())); } @@ -100,7 +100,7 @@ function handle_revive() { $aset = new AssignmentSet($this->user); $aset->override_conflicts(); $aset->enable_papers($this->prow); - $aset->parse("paper,action\n{$this->prow->paperId},revive"); + $aset->parse("application,action\n{$this->prow->paperId},revive"); if (!$aset->execute()) { error_log("{$this->conf->dbname}: revive #{$this->prow->paperId} failure: " . json_encode($aset->json_result())); } diff --git a/src/pages/p_profile.php b/src/pages/p_profile.php index 784e97c6b..7ed98f9d5 100644 --- a/src/pages/p_profile.php +++ b/src/pages/p_profile.php @@ -460,7 +460,7 @@ private function handle_delete() { && !empty($tracks->soleAuthor)) { $this->conf->feedback_msg([ MessageItem::error("<5>This account can’t be deleted because it is sole contact for " . UserStatus::render_paper_link($this->conf, $tracks->soleAuthor)), - MessageItem::inform("<0>You will be able to delete the account after deleting those papers or adding additional paper contacts.") + MessageItem::inform("<0>You will be able to delete the account after deleting those applications or adding additional application contacts.") ]); } else { $this->conf->q("insert into DeletedContactInfo set contactId=?, firstName=?, lastName=?, unaccentedName=?, email=?, affiliation=?", $this->user->contactId, $this->user->firstName, $this->user->lastName, $this->user->unaccentedName, $this->user->email, $this->user->affiliation); @@ -472,7 +472,7 @@ private function handle_delete() { // delete twiddle tags $assigner = new AssignmentSet($this->viewer); $assigner->override_conflicts(); - $assigner->parse("paper,tag\nall,{$this->user->contactId}~all#clear\n"); + $assigner->parse("application,tag\nall,{$this->user->contactId}~all#clear\n"); $assigner->execute(); // clear caches if ($this->user->isPC || $this->user->privChair) { diff --git a/src/pages/p_signin.php b/src/pages/p_signin.php index e9ad92a95..1250caa34 100644 --- a/src/pages/p_signin.php +++ b/src/pages/p_signin.php @@ -197,7 +197,7 @@ static function print_signin_form_description(Contact $user, Qrequest $qreq) { } echo '

    ', $user->conf->_("You are already signed in as %s. Use this form to add another account to this browser session.", commajoin($links)), '

    '; } - if (($t = $user->conf->_("Sign in to submit or review papers.")) !== "") { + if (($t = $user->conf->_("Sign in to submit or review applications.")) !== "") { echo '

    ', $t, '

    '; } } diff --git a/src/pages/p_users.php b/src/pages/p_users.php index 6def2e3e1..2bca1a2ec 100644 --- a/src/pages/p_users.php +++ b/src/pages/p_users.php @@ -49,22 +49,22 @@ function __construct(Contact $viewer, Qrequest $qreq) { if ($viewer->is_manager() || ($viewer->isPC && $this->conf->submission_blindness() !== Conf::BLIND_ALWAYS)) { - $this->limits["au"] = "Contact authors of submitted papers"; + $this->limits["au"] = "Contact authors of submitted applications"; } if ($viewer->is_manager() || ($viewer->isPC && $viewer->can_view_some_decision() && $viewer->can_view_some_authors())) { - $this->limits["auacc"] = ["label" => "Contact authors of accepted papers", "exclude" => !$this->conf->has_any_accepted()]; + $this->limits["auacc"] = ["label" => "Contact authors of accepted applications", "exclude" => !$this->conf->has_any_accepted()]; } if ($viewer->is_manager() || ($viewer->isPC && $viewer->can_view_some_decision() && $this->conf->submission_blindness() !== Conf::BLIND_ALWAYS)) { - $this->limits["aurej"] = "Contact authors of rejected papers"; + $this->limits["aurej"] = "Contact authors of rejected applications"; } if ($viewer->is_manager()) { - $this->limits["auuns"] = "Contact authors of non-submitted papers"; + $this->limits["auuns"] = "Contact authors of non-submitted applications"; } if ($viewer->privChair) { $this->limits["all"] = "Active users"; diff --git a/src/paperlist.php b/src/paperlist.php index b0f8e956b..018d4afbf 100644 --- a/src/paperlist.php +++ b/src/paperlist.php @@ -2028,7 +2028,7 @@ private function _table_render() { $this->_view_kanban = false; } if ($this->count === 0) { - return PaperListTableRender::make_error("No matching papers"); + return PaperListTableRender::make_error("No matching applications"); } // analyze `has`, including authors diff --git a/src/papertable.php b/src/papertable.php index 8053c36bb..1fe662e10 100644 --- a/src/papertable.php +++ b/src/papertable.php @@ -1693,7 +1693,7 @@ private function papstrip_rank($tag) { "id" => "tag:~{$tag} {$this->prow->paperId}"]), ' · ', ' "editsort:#~{$tag}"]), '">Edit all', - '
    Tip: "editsort:#~{$tag}"]), '">Search “editsort:#~', $tag, '” to drag and drop your ranking, or use offline reviewing to rank many papers at once.
    ', + '
    Tip: "editsort:#~{$tag}"]), '">Search “editsort:#~', $tag, '” to drag and drop your ranking, or use offline reviewing to rank many applications at once.
    ', "
    \n"; } @@ -2949,7 +2949,7 @@ private function _mark_review_messages($editable, ReviewInfo $rrow) { } if ($ndelegated == 0) { - $t = "As a secondary reviewer, you can conf->hoturl("assign", "p=$rrow->paperId") . "\">delegate this review to an external reviewer, but if your external reviewer declines to review the paper, you should complete this review yourself."; + $t = "As a secondary reviewer, you can conf->hoturl("assign", "p=$rrow->paperId") . "\">delegate this review to an external reviewer, but if your external reviewer declines to review the application, you should complete this review yourself."; } else if ($rrow->reviewNeedsSubmit == 0) { $t = "A delegated external reviewer has submitted their review, but you can still complete your own if you’d like."; } else if ($napproval) { diff --git a/src/settings/s_banal.php b/src/settings/s_banal.php index 50378710e..0acca8443 100644 --- a/src/settings/s_banal.php +++ b/src/settings/s_banal.php @@ -46,7 +46,7 @@ static function print($id, $sv) { Ht::hidden("format/{$ctr}/id", $id); $sv->print_checkbox("format/{$ctr}/active", "PDF format checker:", ["class" => "uich js-foldup", "group_class" => "form-g has-fold " . ($open ? "foldo" : "foldc"), "group_open" => true]); echo '
    '; - $sv->print_entry_group("format/{$ctr}/papersize", "Paper size", [ + $sv->print_entry_group("format/{$ctr}/papersize", "Application size", [ "horizontal" => true, "readonly" => !$editable, "hint" => "Examples: “letter”, “21cm x 28cm”, “letter OR A4”" @@ -123,7 +123,7 @@ static private function check_banal($sv) { $errors .= "Stderr: 
    " . htmlspecialchars($cf->banal_stderr) . "
    "; } $errors .= "Check: " . $cf->full_feedback_html() . ""; - $sv->warning_at(null, "<5>Running the automated paper checker on a sample PDF file produced unexpected results. You should disable it for now.
    " . foldupbutton(0, "Checker output") . $errors . "
    "); + $sv->warning_at(null, "<5>Running the automated application checker on a sample PDF file produced unexpected results. You should disable it for now.
    " . foldupbutton(0, "Checker output") . $errors . "
    "); if (($s1 == "warning" || $s1 == "error") && $e1_papersize) { $sv->warning_at(null, "<5>(Try setting \$Opt[\"banalZoom\"] to 1.)"); } @@ -175,7 +175,7 @@ static function parse($sv, $ctr, $check) { if ($ss !== "" && ($d = FormatSpec::parse_dimen2($ss))) { $cfs->papersize[] = $d; } else if ($ss !== "") { - $sv->error_at("format/{$ctr}/papersize", "<0>Invalid paper size"); + $sv->error_at("format/{$ctr}/papersize", "<0>Invalid application size"); $problem = true; $sout = null; break; @@ -244,7 +244,7 @@ static function parse($sv, $ctr, $check) { if (preg_match('/^(.*\S)\s+mar(gins?)?/i', $s, $m)) { $s = $m[1]; if (!$cfs->papersize || count($cfs->papersize) !== 1) { - $sv->error_at("format/{$ctr}/papersize", "<0>You must specify a paper size as well as margins"); + $sv->error_at("format/{$ctr}/papersize", "<0>You must specify a application size as well as margins"); $sv->error_at("format/{$ctr}/textblock"); $problem = true; } else { diff --git a/src/userstatus.php b/src/userstatus.php index 7a23e5fef..faba2b09b 100644 --- a/src/userstatus.php +++ b/src/userstatus.php @@ -1547,8 +1547,8 @@ static function print_topics(UserStatus $us) { return; } $us->cs()->add_section_class("w-text fx1")->print_start_section("Topic interests"); - echo '

    Please indicate your interest in reviewing papers on these conference -topics. We use this information to help match papers to reviewers.

    ', + echo '

    Please indicate your interest in reviewing applications on these conference +topics. We use this information to help match applications to reviewers.

    ', Ht::hidden("has_ti", 1), $us->feedback_html_at("ti"), ' diff --git a/test/db.json b/test/db.json index b49d140c4..ec83c2afe 100644 --- a/test/db.json +++ b/test/db.json @@ -54,7 +54,7 @@ { "_id_": 3, "title": "A Simulation Study of IP Switching", - "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this paper, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.", + "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this application, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.", "authors": [ {"name":"Steven Lin", "email": "sclin@leland.stanford.edu", "affiliation": "Stanford University", "contact": true}, {"name":"Nick McKeown", "email": "nickm@ee.stanford.edu", "affiliation": "Stanford University"} @@ -67,7 +67,7 @@ { "_id_": 4, "title": "Scalable High Speed IP Routing Lookups", - "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our paper describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.", + "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our application describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.", "authors": [ {"name":"Marcel Waldvogel", "email": "waldvogel@tik.ee.ethz.ch", "affiliation": "Computer Engineering and Networks Laboratory, ETH Zürich", "contact": true}, {"name":"George Varghese", "email": "varghese@ccrc.wustl.edu", "affiliation": "Computer and Communications Research Center, Washington University in St. Louis", "contact": true}, @@ -93,7 +93,7 @@ { "_id_": 6, "title": "Trace-Based Mobile Network Emulation", - "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this paper, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.", + "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this application, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.", "authors": [ {"name":"Brian Noble", "email": "bnoble@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science", "contact": true}, {"name":"M. Satyanarayanan", "email": "satya@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science"}, @@ -106,7 +106,7 @@ { "_id_": 7, "title": "Fair Scheduling in Wireless Packet Networks", - "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this paper, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.", + "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this application, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.", "authors": [ {"name":"Songwu Lu", "email": "slu@crhc.uiuc.edu", "affiliation": "UIUC", "contact": true}, {"name":"Vaduvur Bharghavan", "email": "bharghav@crhc.uiuc.edu", "affiliation": "UIUC"}, @@ -118,7 +118,7 @@ { "_id_": 8, "title": "Fast Restoration of Real-Time Communication Service from Component Failures in Multi-Hop Networks", - "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this paper, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.", + "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this application, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.", "authors": [ {"name":"Seungjae Han", "email": "sjhan@eecs.umich.edu", "affiliation": "University of Michigan", "contact": true}, {"name":"Kang G. Shin", "email": "kgshin@eecs.umich.edu", "affiliation": "University of Michigan"} @@ -140,7 +140,7 @@ { "_id_": 10, "title": "Active Bridging", - "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This paper describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.", + "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This application describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.", "authors": [ {"name":"D. Scott Alexander", "email": "salex@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania", "contact": true}, {"name":"Marianne Shaw", "email": "marianne@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania"}, @@ -153,7 +153,7 @@ { "_id_": 11, "title": "Internet Routing Instability", - "abstract": "This paper examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this paper, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this paper is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.", + "abstract": "This application examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this application, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this application is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.", "authors": [ {"name":"Craig Labovitz", "email": "labovit@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true}, {"name":"G. Robert Malan", "email": "rmalan@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true}, @@ -165,7 +165,7 @@ { "_id_": 12, "title": "Dynamics of Random Early Detection", - "abstract": "In this paper we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.", + "abstract": "In this application we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.", "authors": [ {"name":"Dong Lin", "affiliation": "Harvard University"}, {"name":"Robert Morris", "email": "rtm@eecs.harvard.edu", "affiliation": "Harvard University", "contact": true} @@ -187,7 +187,7 @@ { "_id_": 14, "title": "Network Performance Effects of HTTP/1.1, CSS1, and PNG", - "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This paper does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.", + "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This application does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.", "authors": [ {"name":"Henrik Frystyk Nielsen", "email": "frystyk@w3.org", "affiliation": "World Wide Web Consortium", "contact": true}, {"name":"James Gettys", "email": "jg@pa.dec.com", "affiliation": "Visiting Scientist, World Wide Web Consortium; Digital Equipment Corporation", "contact": true}, @@ -212,7 +212,7 @@ { "_id_": 16, "title": "Potential Benefits of Delta Encoding and Data Compression for HTTP", - "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous papers have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this paper, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.", + "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous applications have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this application, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.", "authors": [ {"name":"Jeffrey C. Mogul", "email": "mogul@wrl.dec.com", "affiliation": "Digital Equipment Corporation Western Research Laboratory", "contact": true}, {"name":"Fred Douglis", "email": "douglis@research.att.com", "affiliation": "AT&T Labs - Research"}, @@ -225,7 +225,7 @@ { "_id_": 17, "title": "Network Text Editor (NTE): A Scalable Shared Text Editor for the MBone", - "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this paper, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.", + "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this application, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.", "authors": [ {"name":"Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true}, {"name":"Jon Crowcroft", "email": "jon@cs.ucl.ac.uk", "affiliation": "University College London", "contact": true} @@ -236,7 +236,7 @@ { "_id_": 18, "title": "Consistent Overhead Byte Stuffing", - "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this paper as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis paper presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.", + "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this application as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis application presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.", "authors": [ {"name":"Stuart Cheshire", "email": "cheshire@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University", "contact": true}, {"name":"Mary Baker", "email": "mgbaker@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University"} @@ -247,7 +247,7 @@ { "_id_": 19, "title": "A Flow-Based Approach to Datagram Security", - "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this paper, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.", + "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this application, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.", "authors": [ {"name": "Suvo Mittra", "email": "suvo@cs.stanford.edu", "affiliation": "Stanford University", "contact": true}, {"name": "Thomas Y.C. Woo", "email": "woo@research.bell-labs.com", "affiliation": "Bell Laboratories"} @@ -258,7 +258,7 @@ { "_id_": 20, "title": "Best-Effort versus Reservations: A Simple Comparative Analysis", - "abstract": "Using a simple analytical model, this paper addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.", + "abstract": "Using a simple analytical model, this application addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.", "authors": [ {"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center", "contact": true}, {"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"} @@ -269,7 +269,7 @@ { "_id_": 21, "title": "Quality of Service Based Routing: A Performance Perspective", - "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this paper are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The paper also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.", + "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this application are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The application also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.", "authors": [ {"name": "George Apostolopoulos", "affiliation": "University of Maryland"}, {"name": "Roch Guérin", "affiliation": "IBM T. J. Watson Research Center"}, @@ -282,7 +282,7 @@ { "_id_": 22, "title": "Scalable QoS Provision Through Buffer Management", - "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this paper, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.", + "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this application, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.", "authors": [ {"name": "R. Guérin", "email": "guerin@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true}, {"name": "S. Kamat", "email": "sanjay@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true}, @@ -295,7 +295,7 @@ { "_id_": 23, "title": "Data networks as cascades: Explaining the multifractal nature of Internet WAN traffic", - "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this paper provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.", + "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this application provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.", "authors": [ {"name": "A. Feldmann", "email": "anja@research.att.com", "affiliation": "AT&T Labs—Research", "contact": true}, {"name": "A. C. Gilbert", "email": "agilbert@research.att.com", "affiliation": "AT&T Labs—Research"}, @@ -320,7 +320,7 @@ { "_id_": 25, "title": "Secure Group Communications Using Key Graphs", - "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this paper, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.", + "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this application, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.", "authors": [ {"name": "Chung Kei Wong", "email": "ckwong@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin", "contact": true}, {"name": "Mohamed Gouda", "email": "gouda@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin"}, @@ -332,7 +332,7 @@ { "_id_": 26, "title": "Achieving bounded fairness for multicast and TCP traffic in the internet", - "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this paper, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This paper provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.", + "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this application, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This application provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.", "authors": [ {"name": "Huayan Amy Wang", "email": "whycu@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University", "contact": true}, {"name": "Mischa Schwartz", "email": "schwartz@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University"} @@ -358,7 +358,7 @@ { "_id_": 28, "title": "Session Directories and Internet Multicast Address Allocation", - "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this paper we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.", + "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this application we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.", "authors": [ {"name": "Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true} ], @@ -368,7 +368,7 @@ { "_id_": 29, "title": "*Core*-Stateless Fair Queueing: Achieving Approximately Fair Bandwidth Allocations in High Speed Networks", - "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this paper, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.", + "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this application, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.", "authors": [ {"name": "Ion Stoica", "email": "istoica@cs.cmu.edu", "affiliation": "CMU", "contact": true}, {"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox PARC"}, @@ -380,7 +380,7 @@ { "_id_": 30, "title": "Uniform versus Priority Dropping for Layered Video", - "abstract": "In this paper, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.", + "abstract": "In this application, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.", "authors": [ {"name": "Sandeep Bajaj", "email": "bajaj@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"}, {"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"}, diff --git a/test/emails.txt b/test/emails.txt index 91b7e6070..47b797c98 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1922,7 +1922,7 @@ conference. Chris Lilley (World Wide Web Consortium) * Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}} -0 papers were accepted out of {{}} submissions. +0 applications were accepted out of {{}} submissions. Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below. @@ -1943,7 +1943,7 @@ Reviewer expertise ------------------ 2. Some familiarity -Paper summary +Application summary ------------- Summary V @@ -1973,7 +1973,7 @@ conference. Chris Lilley (World Wide Web Consortium) * Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}} -0 papers were accepted out of {{}} submissions. +0 applications were accepted out of {{}} submissions. Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below. diff --git a/test/t_cdb.php b/test/t_cdb.php index 466352ef4..9217cfd94 100644 --- a/test/t_cdb.php +++ b/test/t_cdb.php @@ -237,11 +237,11 @@ function test_author_becomes_contact() { $ps->save_paper_json((object) [ "id" => 1, "authors" => ["puneet@catarina.usc.edu", $user_estrin->email, - $user_floyd->email, $user_van->email, "akhmatova@poema.ru"] + $user_floyd->email, $user_van->email, "akhmatova@poema.ruuu"] ]); $paper1 = $this->user_chair->checked_paper_by_id(1); - $user_anna = user("akhmatova@poema.ru"); + $user_anna = user("akhmatova@poema.ruuu"); xassert(!!$user_anna); xassert($user_anna->act_author_view($paper1)); xassert($user_estrin->act_author_view($paper1)); From 9ace2d4f35a65696d444adb6bcdc31aebf2ff376 Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Wed, 17 Jan 2024 09:38:53 -0800 Subject: [PATCH 2/9] updated conference to program and application --- batch/banaldocstore.php | 2 +- batch/s3test.php | 2 +- batch/s3transfer.php | 2 +- batch/s3verifyall.php | 2 +- batch/savepapers.php | 2 +- batch/updatecontactdb.php | 6 +++--- etc/helptopics.json | 2 +- etc/mailtemplates.json | 6 +++--- etc/msgs.json | 4 ++-- etc/settinggroups.json | 4 ++-- lib/createdb.sh | 6 +++--- package.json | 2 +- src/help/h_chairsguide.php | 10 +++++----- src/help/h_developer.php | 4 ++-- src/help/h_jsonsettings.php | 12 ++++++------ src/help/h_revround.php | 2 +- src/help/h_search.php | 4 ++-- src/help/h_votetags.php | 2 +- src/multiconference.php | 12 ++++++------ src/pages/p_adminhome.php | 6 +++--- src/pages/p_mail.php | 2 +- src/pages/p_mergeaccounts.php | 4 ++-- src/pages/p_offline.php | 2 +- src/pages/p_signin.php | 2 +- src/paperoption.php | 2 +- src/permissionproblem.php | 2 +- src/reviewform.php | 2 +- src/settings/s_review.php | 2 +- src/userstatus.php | 4 ++-- 29 files changed, 57 insertions(+), 57 deletions(-) diff --git a/batch/banaldocstore.php b/batch/banaldocstore.php index 99b5619c7..119f6794a 100644 --- a/batch/banaldocstore.php +++ b/batch/banaldocstore.php @@ -22,7 +22,7 @@ function __construct(Conf $conf, $arg) { $this->count = $arg["count"] ?? 10; if (!($dp = $this->conf->docstore())) { - throw new ErrorException("Conference has no document store"); + throw new ErrorException("Program has no document store"); } $matcher = new DocumentHashMatcher($arg["match"] ?? null); $matcher->set_extension(".pdf"); diff --git a/batch/s3test.php b/batch/s3test.php index d625d174e..b74342c1c 100644 --- a/batch/s3test.php +++ b/batch/s3test.php @@ -89,7 +89,7 @@ static function make_args($argv) { $conf = initialize_conf($arg["config"] ?? null, $arg["name"] ?? null); if (!$conf->setting_data("s3_bucket")) { - throw new ErrorException("S3 is not configured for this conference"); + throw new ErrorException("S3 is not configured for this program"); } return new S3Test_Batch($conf, $arg); } diff --git a/batch/s3transfer.php b/batch/s3transfer.php index bbda3d87c..75f91e440 100644 --- a/batch/s3transfer.php +++ b/batch/s3transfer.php @@ -110,7 +110,7 @@ static function make_args($argv) { $conf = initialize_conf($arg["config"] ?? null, $arg["name"] ?? null); if (!$conf->setting_data("s3_bucket")) { - throw new ErrorException("S3 is not configured for this conference"); + throw new ErrorException("S3 is not configured for this program"); } return new S3Transfer_Batch($conf, $arg); } diff --git a/batch/s3verifyall.php b/batch/s3verifyall.php index 4aa4e025b..768a73d4a 100644 --- a/batch/s3verifyall.php +++ b/batch/s3verifyall.php @@ -141,7 +141,7 @@ static function make_args($argv) { $conf = initialize_conf($arg["config"] ?? null, $arg["name"] ?? null); if (!$conf->setting_data("s3_bucket")) { - throw new ErrorException("S3 is not configured for this conference"); + throw new ErrorException("S3 is not configured for this program"); } return new S3VerifyAll_Batch($conf, $arg); } diff --git a/batch/savepapers.php b/batch/savepapers.php index 722ba5b89..cbcf2b991 100644 --- a/batch/savepapers.php +++ b/batch/savepapers.php @@ -294,7 +294,7 @@ static function run_args($argv) { "disable-users,disable Disable all newly created users", "ignore-pid Ignore `pid` JSON elements", "match-title Match applications by title if no `pid`", - "add-topics Add all referenced topics to conference", + "add-topics Add all referenced topics to program", "no-log Don’t modify the action log" )->helpopt("help") ->description("Change applications as specified by FILE, a JSON object or array of objects. diff --git a/batch/updatecontactdb.php b/batch/updatecontactdb.php index 62670299a..be51cdcc8 100644 --- a/batch/updatecontactdb.php +++ b/batch/updatecontactdb.php @@ -49,7 +49,7 @@ private function try_cdb() { $result = Dbl::ql($cdb, "select * from Conferences where `dbname`=?", $this->conf->dbname); $this->confrow = Dbl::fetch_first_object($result); if (!$this->confrow) { - throw new ErrorException("Conference is not recorded in contactdb"); + throw new ErrorException("Program is not recorded in contactdb"); } $this->cdb_confid = $this->confrow->confid = (int) $this->confrow->confid; $qf = $qv = []; @@ -86,7 +86,7 @@ private function try_cdb() { private function cdb() { $cdb = $this->try_cdb(); if (!$cdb) { - throw new ErrorException("Conference has no contactdb"); + throw new ErrorException("Program has no contactdb"); } return $cdb; } @@ -267,7 +267,7 @@ static function make_args($argv) { "collaborators", "authors", "V,verbose" - )->description("Update HotCRP contactdb for a conference. + )->description("Update HotCRP contactdb for a Program. Usage: php batch/updatecontactdb.php [-n CONFID | --config CONFIG] [--papers] [--users] [--collaborators] [--authors]") ->helpopt("help") ->maxarg(0) diff --git a/etc/helptopics.json b/etc/helptopics.json index 455d550cd..3f4d20537 100644 --- a/etc/helptopics.json +++ b/etc/helptopics.json @@ -1,7 +1,7 @@ [ { "name": "chair", "title": "Chair’s guide", "order": 0, - "description": "<0>How to run a conference using HotCRP." + "description": "<0>How to run a program using HotCRP." }, { "name": "chair/presubmission", "order": 0, diff --git a/etc/mailtemplates.json b/etc/mailtemplates.json index 8a027b714..5527deedc 100644 --- a/etc/mailtemplates.json +++ b/etc/mailtemplates.json @@ -299,7 +299,7 @@ "subject": "[%CONFSHORTNAME%] Withdrawn submission #%NUMBER% %TITLEHINT%", "body": [ "Greetings,\n\n", - "%CONFSHORTNAME% submission #%NUMBER%, which you reviewed or were assigned to review, has been withdrawn from consideration for the conference.\n\n", + "%CONFSHORTNAME% submission #%NUMBER%, which you reviewed or were assigned to review, has been withdrawn from consideration for the program.\n\n", "%IF(ADMINUPDATE)%An administrator withdrew the submission.%ELSE%Authors can withdraw submissions during the review process.%ENDIF%%IF(REASON)% They provided this reason: %REASON%%ENDIF%\n\n", "* Title: %TITLE%\n", "* Author(s): %OPT(AUTHORS)%\n", @@ -700,7 +700,7 @@ "subject": "[%CONFSHORTNAME%] Accepted submission #%NUMBER% %TITLEHINT%", "body": [ "Dear author(s),\n\n", - "The %CONFNAME% program committee is delighted to inform you that your submission #%NUMBER% has been accepted to appear in the conference.\n\n", + "The %CONFNAME% program committee is delighted to inform you that your submission #%NUMBER% has been accepted to appear in the program.\n\n", "* Title: %TITLE%\n", "* Author(s): %OPT(AUTHORS)%\n", "* Site: %URL(paper, p=%NUMBER%, %AUTHORVIEWCAPABILITY%)%\n\n", @@ -721,7 +721,7 @@ "subject": "[%CONFSHORTNAME%] Rejected submission #%NUMBER% %TITLEHINT%", "body": [ "Dear author(s),\n\n", - "The %CONFNAME% program committee is sorry to inform you that your submission #%NUMBER% was rejected, and will not appear in the conference.\n\n", + "The %CONFNAME% program committee is sorry to inform you that your submission #%NUMBER% was rejected, and will not appear in the program.\n\n", "* Title: %TITLE%\n", "* Author(s): %OPT(AUTHORS)%\n", "* Site: %URL(paper, p=%NUMBER%, %AUTHORVIEWCAPABILITY%)%\n\n", diff --git a/etc/msgs.json b/etc/msgs.json index 2ab1dfa55..dd7257198 100644 --- a/etc/msgs.json +++ b/etc/msgs.json @@ -159,8 +159,8 @@ ["mail", "Authors", "Author", ["$1=1"]], - ["resp_instrux", "The authors’ response should address reviewer concerns and correct misunderstandings. Make it short and to the point; the conference deadline has passed."], - ["resp_instrux", "The authors’ response should address reviewer concerns and correct misunderstandings. Make it short and to the point; the conference deadline has passed. Try to stay within {wordlimit} words.", ["{wordlimit}>0"]], + ["resp_instrux", "The authors’ response should address reviewer concerns and correct misunderstandings. Make it short and to the point; the program deadline has passed."], + ["resp_instrux", "The authors’ response should address reviewer concerns and correct misunderstandings. Make it short and to the point; the program deadline has passed. Try to stay within {wordlimit} words.", ["{wordlimit}>0"]], {"id": "conflictdef", "itext": "This includes past advisors and students, people with the same affiliation, and any recent (~2 years) coauthors and collaborators.", "template": true}, diff --git a/etc/settinggroups.json b/etc/settinggroups.json index 0102b1c5f..c65bf5e43 100644 --- a/etc/settinggroups.json +++ b/etc/settinggroups.json @@ -1,13 +1,13 @@ [ { "name": "basics", "order": 0, "title": "Basics", - "description": "<0>Conference name, site contact, and email." + "description": "<0>Program name, site contact, and email." }, { "name": "info", "alias": "basics" }, { "name": "basics/names", "order": 10, "print_function": "Basics_SettingParser::print_names", - "title": "Conference information", + "title": "Program information", "settings": [ "conference_abbreviation", "conference_name", diff --git a/lib/createdb.sh b/lib/createdb.sh index d97871c67..5ea28481a 100755 --- a/lib/createdb.sh +++ b/lib/createdb.sh @@ -155,7 +155,7 @@ if ! $quiet && ! $batch && ! [ -n "$options_file" -a -f "$options_file" ]; then echo "* You are responsible for supporting this installation." 1>&2 echo "*" 1>&2 echo "* Supported installations are available at https://hotcrp.com/" 1>&2 - echo "* for a per-submission fee (ACM- and USENIX-sponsored conferences" 1>&2 + echo "* for a per-submission fee (ACM- and USENIX-sponsored programs" 1>&2 echo "* can take advantage of site-wide agreements)." 1>&2 echo 1>&2 while true; do @@ -202,9 +202,9 @@ fi if ! $batch; then if $dbuser_existing; then - echo "Creating the database for your conference." + echo "Creating the database for your program." else - echo "Creating the database and database user for your conference." + echo "Creating the database and database user for your program." fi if test -z "$granthosts"; then echo "* Access for the database user is allowed only from the local host." diff --git a/package.json b/package.json index 8c842e4b6..f6a1f5754 100644 --- a/package.json +++ b/package.json @@ -3,7 +3,7 @@ "eslint": "^8.21.0" }, "name": "hotcrp", - "description": "HotCRP Conference Review Software", + "description": "HotCRP Application Review Software", "version": "3.0.0", "repository": { "type": "git", diff --git a/src/help/h_chairsguide.php b/src/help/h_chairsguide.php index 6ff2de895..ea1f07886 100644 --- a/src/help/h_chairsguide.php +++ b/src/help/h_chairsguide.php @@ -119,7 +119,7 @@ static function print_assignments(HelpRenderer $hth, $gj) { " Tracks give chairs fine-grained control over PC members’ access rights for individual applications. Example situations calling for tracks include external review committees, PC-paper review committees, and - multi-track conferences.\n"; + multi-track programs.\n"; } else if ($gj->itemid === 6) { echo "

  • ", $hth->hotlink("Collect review preferences from the PC.", "reviewprefs"), " @@ -166,7 +166,7 @@ static function print_assignments(HelpRenderer $hth, $gj) { static function print_chair_conflicts(HelpRenderer $hth) { echo $hth->subhead("Chair conflicts"); echo "

    Chairs and system administrators can access any information stored in the -conference system, including reviewer identities for conflicted applications. +program system, including reviewer identities for conflicted applications. It is easiest to simply accept such conflicts as a fact of life. Chairs who can’t handle conflicts fairly shouldn’t be chairs. However, HotCRP does offer other mechanisms for conflicted reviews.

    @@ -177,7 +177,7 @@ static function print_chair_conflicts(HelpRenderer $hth) { “Override conflicts” to access the assignment page.) Application administrators have full privilege to assign and view reviews for their applications, and can, for example, use the autoassignment tool, but they cannot change -conference settings. When a application +program settings. When a application has an administrator, chair conflicts cannot be overridden.

    Application administrators make life easy for PC reviewers and greatly restrict @@ -219,7 +219,7 @@ static function print_premeeting(HelpRenderer $hth, $gj) { echo "

  • Set ", $hth->setting_link("PC can see review contents", "review_visibility_pc"), " to “Yes” (optional). This opens up the reviews to the program committee, allowing everyone to see scores and read reviews for non-conflicted applications. - (During most conferences’ review periods, a PC member can see a application’s reviews + (During most programs’ review periods, a PC member can see a application’s reviews only after completing their own review for that application.)

    • \n"; } else if ($gj->itemid === 3) { @@ -291,7 +291,7 @@ static function print_atmeeting(HelpRenderer $hth, $gj) { " to expose decisions to PC members if desired.

    \n"; } else if ($gj->itemid === 4) { - echo "

  • Shepherding (optional). If your conference uses + echo "

  • Shepherding (optional). If your program uses shepherding for accepted applications, you can assign shepherds either ", $hth->hotlink("application by application", "paper"), " or ", $hth->hotlink("automatically", "autoassign", "t=accepted"), ".

    • \n"; } diff --git a/src/help/h_developer.php b/src/help/h_developer.php index 9735c7dc5..c02516c04 100644 --- a/src/help/h_developer.php +++ b/src/help/h_developer.php @@ -61,7 +61,7 @@ function print_usage() { function print_settings() { echo "

    The chair-only api/settings endpoint accesses -conference settings in ", +program settings in ", $this->hth->hotlink("JSON format", "help", ["t" => "jsonsettings"]) . ". To modify settings, use the POST method and provide a JSON request body. Examples:

    @@ -91,7 +91,7 @@ function print_settings() { } function print_submissions() { - echo "

    The api/paper endpoint accesses conference + echo "

    The api/paper endpoint accesses program submissions. GET calls return paper information; use api/PAPERID/paper to return one application, and api/paper?q=SEARCH&t=SEARCHTYPE to return all applications matching diff --git a/src/help/h_jsonsettings.php b/src/help/h_jsonsettings.php index 09b4d1215..a75e0b513 100644 --- a/src/help/h_jsonsettings.php +++ b/src/help/h_jsonsettings.php @@ -20,7 +20,7 @@ function print() { echo "

    With ", $this->hth->setting_group_link("Settings > Advanced", "json"), ", administrators can configure site operation by modifying a JSON -specification. Advanced users can copy settings from one conference to +specification. Advanced users can copy settings from one program to another and configure aspects of the site not accessible via the normal settings UI.

    "; @@ -107,11 +107,11 @@ class=\"language-json\">\"SETTINGNAME_reset\": false component to your \"delete\": true to its object.

    -

  • Copying settings between conferences. Beware of IDs -when copying settings between conferences. Unless you are careful, the IDs -used in one conference may differ from the IDs in another. Consider removing -the IDs from a conference’s JSON settings before uploading those settings to -another conference.

    • +

  • Copying settings between programs. Beware of IDs +when copying settings between programs. Unless you are careful, the IDs +used in one program may differ from the IDs in another. Consider removing +the IDs from a program's JSON settings before uploading those settings to +another program.

  • Other common components in object lists include diff --git a/src/help/h_revround.php b/src/help/h_revround.php index f813e2fad..7c5c5cd45 100644 --- a/src/help/h_revround.php +++ b/src/help/h_revround.php @@ -4,7 +4,7 @@ class RevRound_HelpTopic { static function print(HelpRenderer $hth) { - echo "

    Many conferences divide their review assignments into named rounds, + echo "

    Many programs divide their review assignments into named rounds, such as “R1” or “lastround”. (We suggest very short names like “R1”.) Different review rounds can have different deadlines and can even have different fields on their review forms. diff --git a/src/help/h_search.php b/src/help/h_search.php index 15004717c..32ddbcb02 100644 --- a/src/help/h_search.php +++ b/src/help/h_search.php @@ -33,7 +33,7 @@ static function print(HelpRenderer $hth) { " and use “With any of the words” and “Without the words.”

    You can search several categories, depending on your role in the -conference. Options include:

    +program. Options include:

    • ", PaperSearch::limit_description($hth->conf, "s"), " — all submissions ready for review.
    • ", PaperSearch::limit_description($hth->conf, "a"), " — submissions for which you’re a contact.
      • @@ -43,7 +43,7 @@ static function print(HelpRenderer $hth) {

    Search won’t show you information you aren’t supposed to see. For example, -authors can only search their own submissions, and if the conference used +authors can only search their own submissions, and if the program used anonymous submission, then only the PC chairs can search by author.

    By default, search examines titles, abstracts, and authors. ", diff --git a/src/help/h_votetags.php b/src/help/h_votetags.php index 81371d7fd..b493ffa41 100644 --- a/src/help/h_votetags.php +++ b/src/help/h_votetags.php @@ -5,7 +5,7 @@ class VoteTags_HelpTopic { static function print(HelpRenderer $hth) { $votetag = $hth->example_tag("allotment"); - echo "

    Some conferences have PC members vote for applications. In + echo "

    Some programs have PC members vote for applications. In allotment voting, each PC member is assigned a vote allotment to distribute among unconflicted applications; a PC member might assign one vote to one submission and five to another. In approval voting, each PC member diff --git a/src/multiconference.php b/src/multiconference.php index cb6c5eb51..142c88d82 100644 --- a/src/multiconference.php +++ b/src/multiconference.php @@ -169,9 +169,9 @@ static private function make_qrequest() { /** @return string */ static private function nonexistence_error() { if (PHP_SAPI === "cli") { - return "Conference not specified. Use `-n CONFID` to specify a conference."; + return "Program not specified. Use `-n CONFID` to specify a program."; } else { - return "Conference not specified."; + return "Program not specified."; } } @@ -208,7 +208,7 @@ static function fail_bad_options() { } }, $missing)); } else if ($invalid) { - $errors[] = "Invalid conference specified with `-n`."; + $errors[] = "Invalid program specified with `-n`."; } else if ($multiconference && $confid === "__nonexistent__") { $errors[] = self::nonexistence_error(); } else { @@ -218,7 +218,7 @@ static function fail_bad_options() { if (!($Opt["loaded"] ?? null)) { $main_options = defined("HOTCRP_OPTIONS") ? HOTCRP_OPTIONS : SiteLoader::$root . "/conf/options.php"; if (!file_exists($main_options)) { - $errors[] = "HotCRP has been installed, but not yet configured. You must run `lib/createdb.sh` to create a database for your conference. See `README.md` for further guidance."; + $errors[] = "HotCRP has been installed, but not yet configured. You must run `lib/createdb.sh` to create a database for your program. See `README.md` for further guidance."; } else { $errors[] = "HotCRP was unable to load. A system administrator must fix this problem."; } @@ -226,7 +226,7 @@ static function fail_bad_options() { $errors[] = self::nonexistence_error(); } else { if ($multiconference) { - $errors[] = "The “{$confid}” conference does not exist. Check your URL to make sure you spelled it correctly."; + $errors[] = "The “{$confid}” program does not exist. Check your URL to make sure you spelled it correctly."; } if (!empty($missing)) { $errors[] = "Unable to load " . plural_word(count($missing), "configuration file") . " " . commajoin($missing) . "."; @@ -252,7 +252,7 @@ static function fail_bad_database() { if ($multiconference && $confid === "__nonexistent__") { $errors[] = self::nonexistence_error(); } else if ($multiconference) { - $errors[] = "The “{$confid}” conference does not exist. Check your URL to make sure you spelled it correctly."; + $errors[] = "The “{$confid}” program does not exist. Check your URL to make sure you spelled it correctly."; } else { $errors[] = "HotCRP was unable to connect to its database. A system administrator must fix this problem."; if (defined("HOTCRP_TESTHARNESS")) { diff --git a/src/pages/p_adminhome.php b/src/pages/p_adminhome.php index e8e15da4e..59a692022 100644 --- a/src/pages/p_adminhome.php +++ b/src/pages/p_adminhome.php @@ -58,14 +58,14 @@ static function print(Contact $user) { } // Conference names if ($conf->opt("shortNameDefaulted")) { - $ml[] = new MessageItem(null, "<5>hoturl("settings", "group=basics") . "\">Set the conference abbreviation to a short name for your conference, such as “OSDI ’14”", MessageSet::WARNING_NOTE); + $ml[] = new MessageItem(null, "<5>hoturl("settings", "group=basics") . "\">Set the program abbreviation to a short name for your program, such as “OSDI ’14”", MessageSet::WARNING_NOTE); } else if (simplify_whitespace($conf->short_name) != $conf->short_name) { - $ml[] = new MessageItem(null, "<5>The hoturl("settings", "group=basics") . "\">conference abbreviation setting has a funny value. To fix it, remove leading and trailing spaces, use only space characters (no tabs or newlines), and make sure words are separated by single spaces (never two or more)", MessageSet::WARNING); + $ml[] = new MessageItem(null, "<5>The hoturl("settings", "group=basics") . "\">program abbreviation setting has a funny value. To fix it, remove leading and trailing spaces, use only space characters (no tabs or newlines), and make sure words are separated by single spaces (never two or more)", MessageSet::WARNING); } // Site contact $site_contact = $conf->site_contact(); if (!$site_contact->email || $site_contact->email == "you@example.com") { - $ml[] = new MessageItem(null, "<5>hoturl("settings", "group=basics") . "\">Set the conference contact’s name and email so submitters can reach someone if things go wrong", MessageSet::URGENT_NOTE); + $ml[] = new MessageItem(null, "<5>hoturl("settings", "group=basics") . "\">Set the program contact’s name and email so submitters can reach someone if things go wrong", MessageSet::URGENT_NOTE); } // Can anyone view submissions? if ($conf->has_tracks()) { diff --git a/src/pages/p_mail.php b/src/pages/p_mail.php index 0be612f9c..f73d4d1b3 100644 --- a/src/pages/p_mail.php +++ b/src/pages/p_mail.php @@ -259,7 +259,7 @@ function print_template() { Ht::button("Change template", ["id" => "template-changer", "class" => "ui js-mail-set-template"]), ''; } else { echo '

    ', Ht::button("Load template", ["class" => "ui js-mail-set-template"]), '
    ', - '
    Templates are mail texts tailored for common conference tasks.
    '; + '
    Templates are mail texts tailored for common program tasks.
    '; } echo ''; } diff --git a/src/pages/p_mergeaccounts.php b/src/pages/p_mergeaccounts.php index d891754c7..b4cdce63d 100644 --- a/src/pages/p_mergeaccounts.php +++ b/src/pages/p_mergeaccounts.php @@ -44,7 +44,7 @@ private function handle_merge() { return false; } if (!$this->user->contactId && !$other->contactId) { - $this->conf->warning_msg("<0>Neither of those accounts has any data associated with this conference"); + $this->conf->warning_msg("<0>Neither of those accounts has any data associated with this program"); return false; } if ($other->contactId && $other->contactId === $this->user->contactId) { @@ -94,7 +94,7 @@ private function print() { 'You may have multiple accounts registered; perhaps you were asked to review papers using different email addresses. This form will allow you to transfer information between accounts, including authorship, reviews, and PC status. (Note that the -transfer will only affect information currently stored in this conference.)

    '; +transfer will only affect information currently stored in this program.)

    '; echo Ht::form($this->conf->hoturl("=mergeaccounts")), '
    ', diff --git a/src/pages/p_offline.php b/src/pages/p_offline.php index 1cf9da913..77842b59c 100644 --- a/src/pages/p_offline.php +++ b/src/pages/p_offline.php @@ -167,7 +167,7 @@ static function go(Contact $user, Qrequest $qreq) { if (!$user->email) { $user->escape(); } else if (!$user->is_reviewer()) { - Multiconference::fail($qreq, 403, ["title" => "Offline reviewing"], "<0>You aren’t registered as a reviewer or PC member for this conference"); + Multiconference::fail($qreq, 403, ["title" => "Offline reviewing"], "<0>You aren’t registered as a reviewer or PC member for this program"); } else if (!$user->conf->time_review_open() && !$user->privChair) { Multiconference::fail($qreq, 403, ["title" => "Offline reviewing"], "<0>The site is not open for review"); } diff --git a/src/pages/p_signin.php b/src/pages/p_signin.php index 1250caa34..b668e86f4 100644 --- a/src/pages/p_signin.php +++ b/src/pages/p_signin.php @@ -505,7 +505,7 @@ function reset_request(Contact $user, Qrequest $qreq) { self::bad_post_error($user, $qreq, "resetpassword"); } } else if ($this->_reset_token) { - $this->ms()->error_at("resetcap", "This password reset code refers to a user who no longer exists. Either create a new account or contact the conference administrator."); + $this->ms()->error_at("resetcap", "This password reset code refers to a user who no longer exists. Either create a new account or contact the program administrator."); } } private function reset_valid_post_request(Contact $user, Qrequest $qreq) { diff --git a/src/paperoption.php b/src/paperoption.php index 0853a7eaf..1221310ab 100644 --- a/src/paperoption.php +++ b/src/paperoption.php @@ -30,7 +30,7 @@ function __construct(Conf $conf) { function _add_json($oj, $k) { if (!isset($oj->id) && $k === 0) { - throw new ErrorException("This conference could not be upgraded from an old database schema. A system administrator must fix this problem."); + throw new ErrorException("This program could not be upgraded from an old database schema. A system administrator must fix this problem."); } if (is_string($oj->id) && is_numeric($oj->id)) { // XXX backwards compat $oj->id = intval($oj->id); diff --git a/src/permissionproblem.php b/src/permissionproblem.php index 403bd1a13..c9a962ae2 100644 --- a/src/permissionproblem.php +++ b/src/permissionproblem.php @@ -243,7 +243,7 @@ function unparse($format = 0) { $ms[] = $this->conf->_("<0>“Override deadlines” can override this restriction."); } if ($this->_a["blindSubmission"] ?? false) { - $ms[] = $this->conf->_("<0>Submission to this conference is blind."); + $ms[] = $this->conf->_("<0>Submission to this program is blind."); } if ($this->_a["author"] ?? false) { $ms[] = $this->conf->_("<0>You aren’t a contact for #{}.", $paperId); diff --git a/src/reviewform.php b/src/reviewform.php index 3a2c287d0..f9a933ff7 100644 --- a/src/reviewform.php +++ b/src/reviewform.php @@ -963,7 +963,7 @@ function parse_text($override) { if (preg_match('/\A==\+==\s+(.*?)\s+(Paper Review(?: Form)?s?)\s*\z/', $line, $m) && $m[1] != $this->conf->short_name) { $this->check_garbage(); - $this->rmsg("confid", "<0>Ignoring review form, which appears to be for a different conference.", self::ERROR); + $this->rmsg("confid", "<0>Ignoring review form, which appears to be for a different program.", self::ERROR); $this->rmsg("confid", "<5>(If this message is in error, replace the line that reads “" . htmlspecialchars(rtrim($line)) . "” with “==+== " . htmlspecialchars($this->conf->short_name) . " " . $m[2] . "” and upload again.)", self::INFORM); return false; } else if (preg_match('/\A==\+== Begin Review/i', $line)) { diff --git a/src/settings/s_review.php b/src/settings/s_review.php index 16d5431df..3e9f64102 100644 --- a/src/settings/s_review.php +++ b/src/settings/s_review.php @@ -161,7 +161,7 @@ private static function print_round($sv, $ctr, $round_map) { static function print_rounds(SettingValues $sv) { Icons::stash_defs("trash"); - echo '

    Reviews are due by the deadline, but cannot be modified after the hard deadline. Most conferences don’t use hard deadlines for reviews.

    ', + echo '

    Reviews are due by the deadline, but cannot be modified after the hard deadline. Most programs don’t use hard deadlines for reviews.

    ', '

    ', $sv->type_hint("date"), '

    ', Ht::hidden("has_review", 1), Ht::unstash(); diff --git a/src/userstatus.php b/src/userstatus.php index faba2b09b..965835161 100644 --- a/src/userstatus.php +++ b/src/userstatus.php @@ -1547,7 +1547,7 @@ static function print_topics(UserStatus $us) { return; } $us->cs()->add_section_class("w-text fx1")->print_start_section("Topic interests"); - echo '

    Please indicate your interest in reviewing applications on these conference + echo '

    Please indicate your interest in reviewing applications on these program topics. We use this information to help match applications to reviewers.

    ', Ht::hidden("has_ti", 1), $us->feedback_html_at("ti"), @@ -1646,7 +1646,7 @@ static function print_main_actions(UserStatus $us) { $p = "

    Disabled accounts cannot sign in or view the site."; } else { $klass = "flex-grow-1 disabled"; - $p = "

    Conference settings prevent this account from being enabled."; + $p = "

    Program settings prevent this account from being enabled."; } echo Ht::button($disablement ? "Enable account" : "Disable account", [ "class" => $klass, "disabled" => $no_change From ea352d677f66146080e235b169dcc10aea69c534 Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Thu, 18 Jan 2024 15:04:54 -0800 Subject: [PATCH 3/9] modified email with ruuu to ru - as I was just concern about email with domain from .ru --- test/t_cdb.php | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/t_cdb.php b/test/t_cdb.php index 9217cfd94..466352ef4 100644 --- a/test/t_cdb.php +++ b/test/t_cdb.php @@ -237,11 +237,11 @@ function test_author_becomes_contact() { $ps->save_paper_json((object) [ "id" => 1, "authors" => ["puneet@catarina.usc.edu", $user_estrin->email, - $user_floyd->email, $user_van->email, "akhmatova@poema.ruuu"] + $user_floyd->email, $user_van->email, "akhmatova@poema.ru"] ]); $paper1 = $this->user_chair->checked_paper_by_id(1); - $user_anna = user("akhmatova@poema.ruuu"); + $user_anna = user("akhmatova@poema.ru"); xassert(!!$user_anna); xassert($user_anna->act_author_view($paper1)); xassert($user_estrin->act_author_view($paper1)); From 442824dce44a899d29421eb64ad0f7ccb540355e Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Thu, 18 Jan 2024 15:41:15 -0800 Subject: [PATCH 4/9] fixed tests --- test/db.json | 44 ++++++++++++++++++++++---------------------- test/emails.txt | 6 +++--- 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/test/db.json b/test/db.json index ec83c2afe..b49d140c4 100644 --- a/test/db.json +++ b/test/db.json @@ -54,7 +54,7 @@ { "_id_": 3, "title": "A Simulation Study of IP Switching", - "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this application, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.", + "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this paper, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.", "authors": [ {"name":"Steven Lin", "email": "sclin@leland.stanford.edu", "affiliation": "Stanford University", "contact": true}, {"name":"Nick McKeown", "email": "nickm@ee.stanford.edu", "affiliation": "Stanford University"} @@ -67,7 +67,7 @@ { "_id_": 4, "title": "Scalable High Speed IP Routing Lookups", - "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our application describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.", + "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our paper describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.", "authors": [ {"name":"Marcel Waldvogel", "email": "waldvogel@tik.ee.ethz.ch", "affiliation": "Computer Engineering and Networks Laboratory, ETH Zürich", "contact": true}, {"name":"George Varghese", "email": "varghese@ccrc.wustl.edu", "affiliation": "Computer and Communications Research Center, Washington University in St. Louis", "contact": true}, @@ -93,7 +93,7 @@ { "_id_": 6, "title": "Trace-Based Mobile Network Emulation", - "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this application, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.", + "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this paper, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.", "authors": [ {"name":"Brian Noble", "email": "bnoble@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science", "contact": true}, {"name":"M. Satyanarayanan", "email": "satya@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science"}, @@ -106,7 +106,7 @@ { "_id_": 7, "title": "Fair Scheduling in Wireless Packet Networks", - "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this application, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.", + "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this paper, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.", "authors": [ {"name":"Songwu Lu", "email": "slu@crhc.uiuc.edu", "affiliation": "UIUC", "contact": true}, {"name":"Vaduvur Bharghavan", "email": "bharghav@crhc.uiuc.edu", "affiliation": "UIUC"}, @@ -118,7 +118,7 @@ { "_id_": 8, "title": "Fast Restoration of Real-Time Communication Service from Component Failures in Multi-Hop Networks", - "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this application, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.", + "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this paper, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.", "authors": [ {"name":"Seungjae Han", "email": "sjhan@eecs.umich.edu", "affiliation": "University of Michigan", "contact": true}, {"name":"Kang G. Shin", "email": "kgshin@eecs.umich.edu", "affiliation": "University of Michigan"} @@ -140,7 +140,7 @@ { "_id_": 10, "title": "Active Bridging", - "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This application describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.", + "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This paper describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.", "authors": [ {"name":"D. Scott Alexander", "email": "salex@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania", "contact": true}, {"name":"Marianne Shaw", "email": "marianne@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania"}, @@ -153,7 +153,7 @@ { "_id_": 11, "title": "Internet Routing Instability", - "abstract": "This application examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this application, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this application is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.", + "abstract": "This paper examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this paper, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this paper is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.", "authors": [ {"name":"Craig Labovitz", "email": "labovit@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true}, {"name":"G. Robert Malan", "email": "rmalan@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true}, @@ -165,7 +165,7 @@ { "_id_": 12, "title": "Dynamics of Random Early Detection", - "abstract": "In this application we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.", + "abstract": "In this paper we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.", "authors": [ {"name":"Dong Lin", "affiliation": "Harvard University"}, {"name":"Robert Morris", "email": "rtm@eecs.harvard.edu", "affiliation": "Harvard University", "contact": true} @@ -187,7 +187,7 @@ { "_id_": 14, "title": "Network Performance Effects of HTTP/1.1, CSS1, and PNG", - "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This application does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.", + "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This paper does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.", "authors": [ {"name":"Henrik Frystyk Nielsen", "email": "frystyk@w3.org", "affiliation": "World Wide Web Consortium", "contact": true}, {"name":"James Gettys", "email": "jg@pa.dec.com", "affiliation": "Visiting Scientist, World Wide Web Consortium; Digital Equipment Corporation", "contact": true}, @@ -212,7 +212,7 @@ { "_id_": 16, "title": "Potential Benefits of Delta Encoding and Data Compression for HTTP", - "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous applications have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this application, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.", + "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous papers have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this paper, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.", "authors": [ {"name":"Jeffrey C. Mogul", "email": "mogul@wrl.dec.com", "affiliation": "Digital Equipment Corporation Western Research Laboratory", "contact": true}, {"name":"Fred Douglis", "email": "douglis@research.att.com", "affiliation": "AT&T Labs - Research"}, @@ -225,7 +225,7 @@ { "_id_": 17, "title": "Network Text Editor (NTE): A Scalable Shared Text Editor for the MBone", - "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this application, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.", + "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this paper, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.", "authors": [ {"name":"Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true}, {"name":"Jon Crowcroft", "email": "jon@cs.ucl.ac.uk", "affiliation": "University College London", "contact": true} @@ -236,7 +236,7 @@ { "_id_": 18, "title": "Consistent Overhead Byte Stuffing", - "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this application as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis application presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.", + "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this paper as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis paper presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.", "authors": [ {"name":"Stuart Cheshire", "email": "cheshire@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University", "contact": true}, {"name":"Mary Baker", "email": "mgbaker@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University"} @@ -247,7 +247,7 @@ { "_id_": 19, "title": "A Flow-Based Approach to Datagram Security", - "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this application, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.", + "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this paper, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.", "authors": [ {"name": "Suvo Mittra", "email": "suvo@cs.stanford.edu", "affiliation": "Stanford University", "contact": true}, {"name": "Thomas Y.C. Woo", "email": "woo@research.bell-labs.com", "affiliation": "Bell Laboratories"} @@ -258,7 +258,7 @@ { "_id_": 20, "title": "Best-Effort versus Reservations: A Simple Comparative Analysis", - "abstract": "Using a simple analytical model, this application addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.", + "abstract": "Using a simple analytical model, this paper addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.", "authors": [ {"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center", "contact": true}, {"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"} @@ -269,7 +269,7 @@ { "_id_": 21, "title": "Quality of Service Based Routing: A Performance Perspective", - "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this application are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The application also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.", + "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this paper are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The paper also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.", "authors": [ {"name": "George Apostolopoulos", "affiliation": "University of Maryland"}, {"name": "Roch Guérin", "affiliation": "IBM T. J. Watson Research Center"}, @@ -282,7 +282,7 @@ { "_id_": 22, "title": "Scalable QoS Provision Through Buffer Management", - "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this application, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.", + "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this paper, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.", "authors": [ {"name": "R. Guérin", "email": "guerin@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true}, {"name": "S. Kamat", "email": "sanjay@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true}, @@ -295,7 +295,7 @@ { "_id_": 23, "title": "Data networks as cascades: Explaining the multifractal nature of Internet WAN traffic", - "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this application provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.", + "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this paper provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.", "authors": [ {"name": "A. Feldmann", "email": "anja@research.att.com", "affiliation": "AT&T Labs—Research", "contact": true}, {"name": "A. C. Gilbert", "email": "agilbert@research.att.com", "affiliation": "AT&T Labs—Research"}, @@ -320,7 +320,7 @@ { "_id_": 25, "title": "Secure Group Communications Using Key Graphs", - "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this application, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.", + "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this paper, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.", "authors": [ {"name": "Chung Kei Wong", "email": "ckwong@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin", "contact": true}, {"name": "Mohamed Gouda", "email": "gouda@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin"}, @@ -332,7 +332,7 @@ { "_id_": 26, "title": "Achieving bounded fairness for multicast and TCP traffic in the internet", - "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this application, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This application provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.", + "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this paper, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This paper provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.", "authors": [ {"name": "Huayan Amy Wang", "email": "whycu@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University", "contact": true}, {"name": "Mischa Schwartz", "email": "schwartz@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University"} @@ -358,7 +358,7 @@ { "_id_": 28, "title": "Session Directories and Internet Multicast Address Allocation", - "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this application we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.", + "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this paper we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.", "authors": [ {"name": "Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true} ], @@ -368,7 +368,7 @@ { "_id_": 29, "title": "*Core*-Stateless Fair Queueing: Achieving Approximately Fair Bandwidth Allocations in High Speed Networks", - "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this application, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.", + "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this paper, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.", "authors": [ {"name": "Ion Stoica", "email": "istoica@cs.cmu.edu", "affiliation": "CMU", "contact": true}, {"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox PARC"}, @@ -380,7 +380,7 @@ { "_id_": 30, "title": "Uniform versus Priority Dropping for Layered Video", - "abstract": "In this application, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.", + "abstract": "In this paper, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.", "authors": [ {"name": "Sandeep Bajaj", "email": "bajaj@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"}, {"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"}, diff --git a/test/emails.txt b/test/emails.txt index 47b797c98..91b7e6070 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1922,7 +1922,7 @@ conference. Chris Lilley (World Wide Web Consortium) * Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}} -0 applications were accepted out of {{}} submissions. +0 papers were accepted out of {{}} submissions. Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below. @@ -1943,7 +1943,7 @@ Reviewer expertise ------------------ 2. Some familiarity -Application summary +Paper summary ------------- Summary V @@ -1973,7 +1973,7 @@ conference. Chris Lilley (World Wide Web Consortium) * Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}} -0 applications were accepted out of {{}} submissions. +0 papers were accepted out of {{}} submissions. Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below. From be12164ac9702ab83259ebe09c3936710803519d Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Fri, 19 Jan 2024 10:36:26 -0800 Subject: [PATCH 5/9] testing test cases --- test/emails.txt | 116 ++++++++++++++++++++++++------------------------ 1 file changed, 58 insertions(+), 58 deletions(-) diff --git a/test/emails.txt b/test/emails.txt index 91b7e6070..6fbb192e4 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1,11 +1,11 @@ ******** create-huitema@bellcore.com To: Christian Huitema -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: huitema@bellcore.com @@ -26,12 +26,12 @@ concerns. - Testconf I Submissions ******** create-christophe.diot@sophia.inria.fr To: Christophe Diot -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: christophe.diot@sophia.inria.fr @@ -52,12 +52,12 @@ concerns. - Testconf I Submissions ******** create-estrin@usc.edu To: Deborah Estrin -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: estrin@usc.edu @@ -80,12 +80,12 @@ concerns. ******** create-varghese@ccrc.wustl.edu To: George Varghese -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: varghese@ccrc.wustl.edu @@ -106,12 +106,12 @@ concerns. - Testconf I Submissions ******** create-jj@cse.ucsc.edu To: "J. J. Garcia-Luna-Aceves" -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: jj@cse.ucsc.edu @@ -132,12 +132,12 @@ concerns. - Testconf I Submissions ******** create-jon@cs.ucl.ac.uk To: Jon Crowcroft -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: jon@cs.ucl.ac.uk @@ -158,12 +158,12 @@ concerns. - Testconf I Submissions ******** create-lixia@cs.ucla.edu To: Lixia Zhang -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: lixia@cs.ucla.edu @@ -184,12 +184,12 @@ concerns. - Testconf I Submissions ******** create-marina@poema.ru To: Marina Tsvetaeva -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: marina@poema.ru @@ -210,12 +210,12 @@ concerns. - Testconf I Submissions ******** create-mjh@isi.edu To: Mark Handley -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: mjh@isi.edu @@ -236,12 +236,12 @@ concerns. - Testconf I Submissions ******** create-mgbaker@cs.stanford.edu To: Mary Baker -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: mgbaker@cs.stanford.edu @@ -262,12 +262,12 @@ concerns. - Testconf I Submissions ******** create-pfrancis@ntt.jp To: Paul Francis -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: pfrancis@ntt.jp @@ -288,12 +288,12 @@ concerns. - Testconf I Submissions ******** create-peter.danzig@usc.edu To: Peter Danzig -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: peter.danzig@usc.edu @@ -314,12 +314,12 @@ concerns. - Testconf I Submissions ******** create-pdruschel@cs.rice.edu To: Peter Druschel -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: pdruschel@cs.rice.edu @@ -340,12 +340,12 @@ concerns. - Testconf I Submissions ******** create-rguerin@ibm.com To: Roch Guerin -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: rguerin@ibm.com @@ -366,12 +366,12 @@ concerns. - Testconf I Submissions ******** create-floyd@ee.lbl.gov To: Sally Floyd -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: floyd@ee.lbl.gov @@ -392,12 +392,12 @@ concerns. - Testconf I Submissions ******** create-shenker@parc.xerox.com To: Scott Shenker -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: shenker@parc.xerox.com @@ -420,12 +420,12 @@ concerns. ******** create-ojuelegba@gmail.com To: Wilma Ojuelegba -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: ojuelegba@gmail.com @@ -446,12 +446,12 @@ concerns. - Testconf I Submissions ******** create-vera@bombay.com To: Véra Djükuba -Subject: [Testconf I] Welcome to the program committee +Subject: [Testconf I] Welcome to the adjudication committee Greetings, -You have been added to the program committee on the Test Conference I -(Testconf I) submission site. +You have been added to the adjudication committee on the Test Conference +I (Testconf I) submission site. * Site: http://hotcrp.lcdf.org/test/ * Email: vera@bombay.com @@ -1718,9 +1718,9 @@ X-Landmark: test/test06.php:747 Dear Jo March, -On behalf of the Test Conference I (Testconf I) program committee, Lixia -Zhang has asked you to review Test Conference I -(Testconf I) submission #17. +On behalf of the Test Conference I (Testconf I) adjudication committee, +Lixia Zhang has asked you to review Test Conference +I (Testconf I) submission #17. * Title: Network Text Editor (NTE): A Scalable Shared Text Editor for the MBone @@ -2069,4 +2069,4 @@ Your message here. Contact Eddie Kohler with any questions or concerns. -- Testconf I Submissions +- Testconf I Submissions \ No newline at end of file From 990c0de2d5f1bb38a098044dfab3a03c8f761d40 Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Fri, 19 Jan 2024 10:52:18 -0800 Subject: [PATCH 6/9] testing test cases --- test/emails.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/emails.txt b/test/emails.txt index 6fbb192e4..88635d598 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1135,7 +1135,7 @@ Subject: [Testconf I] Withdrawn submission #1 "Scalable Timers for Soft State Greetings, Testconf I submission #1, which you reviewed or were assigned to review, -has been withdrawn from consideration for the conference. +has been withdrawn from consideration for the program. An administrator withdrew the submission. @@ -1185,7 +1185,7 @@ X-Landmark: test/test01.php:8 Greetings, Testconf I submission #16, which you reviewed or were assigned to -review, has been withdrawn from consideration for the conference. +review, has been withdrawn from consideration for the program. An administrator withdrew the submission. They provided this reason: Suckola From e3b93665a2c3d9a71a2d79fd8aa3820c8e3a26ce Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Fri, 19 Jan 2024 11:21:56 -0800 Subject: [PATCH 7/9] testing test cases --- test/emails.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/test/emails.txt b/test/emails.txt index 88635d598..d1ee7df62 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1909,8 +1909,7 @@ X-Landmark: test/t_paperstatus.php:1114 Dear authors, The Test Conference I (Testconf I) program committee is sorry to inform -you that your submission #14 was rejected, and will not appear in the -conference. +you that your submission #14 was rejected, and will not appear in the program. * Title: Network Performance Effects of HTTP/1.1, CSS1, and PNG * Authors: Henrik Frystyk Nielsen (World Wide Web Consortium); @@ -1960,8 +1959,7 @@ X-Landmark: test/t_paperstatus.php:821 Dear authors, The Test Conference I (Testconf I) program committee is sorry to inform -you that your submission #14 was rejected, and will not appear in the -conference. +you that your submission #14 was rejected, and will not appear in the program. * Title: Network Performance Effects of HTTP/1.1, CSS1, and PNG * Authors: Henrik Frystyk Nielsen (World Wide Web Consortium); From 69171d28b953605989cfe8b8c3c8bc27e18e6fad Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Fri, 19 Jan 2024 13:50:57 -0800 Subject: [PATCH 8/9] testing test case for line break --- test/emails.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/test/emails.txt b/test/emails.txt index d1ee7df62..d1fab36f7 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1952,8 +1952,7 @@ Comments V ******** test05-reject14-2 To: Henrik Frystyk Nielsen , James Gettys , Anselm Baird-Smith , George Varghese -Subject: [Testconf I] Rejected submission #14 "Network Performance Effects of - HTTP/1.1,..." +Subject: [Testconf I] Rejected submission #14 "Network Performance Effects of HTTP/1.1,..." X-Landmark: test/t_paperstatus.php:821 Dear authors, From 8913475f001feab25d3ed496fefca7feb1622ebd Mon Sep 17 00:00:00 2001 From: ubc-tuehoang Date: Fri, 19 Jan 2024 14:04:37 -0800 Subject: [PATCH 9/9] testing test case email --- test/emails.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/emails.txt b/test/emails.txt index d1fab36f7..e5225ae9d 100644 --- a/test/emails.txt +++ b/test/emails.txt @@ -1951,7 +1951,7 @@ Comments for authors Comments V ******** test05-reject14-2 -To: Henrik Frystyk Nielsen , James Gettys , Anselm Baird-Smith , George Varghese +To: Henrik Frystyk Nielsen , James Gettys , Anselm Baird-Smith Subject: [Testconf I] Rejected submission #14 "Network Performance Effects of HTTP/1.1,..." X-Landmark: test/t_paperstatus.php:821