Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cite added, typo fixed #5

Merged
merged 1 commit into from
May 27, 2016
+3 −3
Merged

cite added, typo fixed #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions draft-huitema-dnssd-privacy.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -416,7 +416,7 @@ usability issues.
</t>
</section>

<section title="Names of obfuscated services" >
<section title="Names of obfuscated services">

<t>
Instead of publishing the actual service name in the SRV records,
Expand Down Expand Up @@ -500,7 +500,7 @@ for the server. If clients must use wildcard queries, they will need to process
lots of irrelevant data. If clients need to predict different instance names for
each potential server, they will end up sending batches of queries with many
different names. All of these solutions appear like big departures from the
simplicty and robustness of the DNS-SD design.
simplicity and robustness of the DNS-SD design.
</t>
<t>
Given the relatively low priority of hiding the service name and the complexity
Expand Down Expand Up @@ -744,7 +744,7 @@ instance discovery key
Both problems can be mitigated by using the method described in the following.
</t>
<t>
Privacy Preserving Service Discovery can be divided into three (independent) layers.
Privacy Preserving Service Discovery can be divided into three independent layers <xref target="KW14b" />.
</t>
<t>
<list style="symbols">
Expand Down