Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Am 20.11.2008 um 00:02 schrieb Chris Newman: --On November 4, 2008 6:28:19 -0800 The IESG iesg- [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC end user, I strongly support publication of this document, hello all, if this is the question , i would recomend that as an end- user too , just currious that mr. cheshire does not respond;) What is the title of the registry that will be listed on IANA's web page? Do you believe it would be possible to merge the new service registry with this one: http://www.iana.org/assignments/gssapi-service-names creating a single service-name registry shared by these protocols? have a great day Marc -- Marc Manthey Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 web : http://www.let.de PGP/GnuPG: 0x1ac02f3296b12b4d___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
--On November 4, 2008 6:28:19 -0800 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC As a technical contributor and end user, I strongly support publication of this document, although I would prefer it was on the standards track. I very much appreciate the text discussing why certain design decisions were made, as well as mentioning implementation/UI issues where people made mistakes in the past. Other comments: Section 4: The Instance portion of the Service Instance Name is a single DNS label, containing arbitrary precomposed (Unicode Normalization Form C [UAX15]) UTF-8-encoded text [RFC 3629]. Have you considered referencing RFC 5198 instead? It's based on the same normalization form, but has some minor restrictions/clarifications that are likely to improve interoperability. As your current text allows line breaks (was that intentional?) it would be helpful to have a canonical form for line breaks that 5198 defines. If you didn't intend to allow line breaks you might want to recommend against their use as well. intended to ever be typed in by a user accessing a service; the user accesses a service by selecting its name from a list of choices presented on the screen. Since this list may also be presented by a screen reader to the blind, and selection from the list is a mandatory part of the user experience, have you considered adding a way to include a language tag to assist screen readers in their translation to voice? BCP 18 has some discussion of this. Is there implementation experience that a language tag is not necessary for this situation? Section 19: What is the title of the registry that will be listed on IANA's web page? Do you believe it would be possible to merge the new service registry with this one: http://www.iana.org/assignments/gssapi-service-names creating a single service-name registry shared by these protocols? Thanks, - Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
On Sat Nov 15 23:54:33 2008, Mark Townsley wrote: Dave Cridland wrote: On Tue Nov 4 14:28:19 2008, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC I note that this document is Informational, yet forms the basis for standards track documents both in the IETF and other SDOs. Thank you for your review. Can you point me to any standards track IETF documents which might need normative reference to this document? IETF: http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-03 IETF: http://tools.ietf.org/html/draft-garcia-p2psip-dns-sd-bootstrapping-00 XSF: http://xmpp.org/extensions/xep-0174.html Both the IETF documents have a Normative Ref of dns-sd, the XSF document (also Standards Track, and Draft, hence roughly equivalent to PS) has a formal dependency on it. A cursory web search for dns-sd specification finds published books under the impression that DNS-SD is standards track. Finally, while looking about for other specifications, I noticed this discussion on the KDE list, dating from just over 4 years ago, which left me quite impressed. http://lists.kde.org/?l=kde-develm=109916905222337w=2 I was particularly impressed by the discussion of how DNS-SD and IDNA interact, especially if the resolver is designed to handle transparent IDNA. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Thank you for your review. Can you point me to any standards track IETF documents which might need normative reference to this document? One example: draft-lee-sip-dns-sd-uri-03 Henning ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Dave Cridland wrote: On Tue Nov 4 14:28:19 2008, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC I note that this document is Informational, yet forms the basis for standards track documents both in the IETF and other SDOs. Thank you for your review. Can you point me to any standards track IETF documents which might need normative reference to this document? - Mark It would be, therefore, more useful to tidy up this document and move it to the standards track rather than short-cutting it to an Informational. In the course of reviewing XEP-0174 changes for the XSF, I reviewed this document in detail, particularly on the subject of record formatting. The following are my own views, however, not those of the XSF. I believe the document is exceedingly unclear, and as such unsuitable for publication in its present form. It is badly laid out, and contains a mixture of specification, rationale, marketing, and confusing reiteration of other documents, making the document much harder to extract useful information from than it needs to be. I'm also unconvinced that this represents the state of the protocol as deployed by various Apple devices anyway. If this is to be a serious attempt to document a working protocol, it must reflect reality. Section by Section: 1) The last two paragraphs of the Introduction can largely be snipped. 2) Use of RFC 2119 language in an Informational document is a curious one - I'm not against its use, but in general terms, the document does not appear to use these terms in quite the way I'd expect. In particular, the terms appear to be used to express designer's preferences rather than actual interoperability requirements. 3) Seems okay. 4) Okay. 4.1) The parenthesis in the second paragraph is superfluous - one expects that any reader would surely understand DNS to this level. From about the top of page 6, however, it gets really bad. Only the top paragraph, diagram, and first two sentences of the subsequent paragraph are needed here. The rest of the page is waffle and repetition. Page 7 is mostly okay - it could probably be condensed. I'd question the purpose of Punycode here, though, if the records are already usefully deployed in UTF-8, since the records are only to be found by querying in the first place. Is this actually supported in the field? (As in, do clients try punycode?) 4.2) I'm always a little wary of UI detail in IETF documents, but the suggestions seem reasonable. 4.3) As near as I can tell, the backslah-escaping of DNS-SD instance names is done externally as well as internally, so this section is exceedingly misleading. 4.4) Appears to be largely marketing, or rationale, and is confusing in this section. 4.5) Appears to be largely rationale. 5) Reiterates SRV 6) Okay, although I don't understand the point of mandating an empty TXT record, it being about the only portion of the document not backed up by twenty-five pages of rationale including words like compelling. I'm guessing it might be to avoid negative caching, thus placing the statement This service has no parameters under the control of normal TTL, etc. That would, naturally, be a compelling reason. It's a shame that several TXT records for services are absent on dns-sd.org, then, but it's only a SHOULD - ho, ho. 6.1) Massively confusing, since it reiterates RFC 1035 in such a way that without referring to RFC 1035 to gain the context, one is led to believe that the actual strings must follow this format, instead of it merely being wire format. 6.2) All jolly good, although I note that several Apple devices appear to use a single TXT string containing a comma seperated list of values, that is, if you forgive my pseudo-ABNF: txt_value = txt_record txt_record = keypair [, keypair] Instead of the apparent specification: txt_value = / (1*txt_record) txt_record = keypair I wonder whether this is an earlier version of the specification, or a non-standard usage of a non-standard, or whether even Apple people can't glean the single useful fact from this entire page of prose. 6.3) Astonishingly, this section is reasonably concise, and contains information which is, dare I say it, useful. Thankfully it, too, appears to be ignored by various Apple devices. 6.4) This section could usefully be folded into 6.2, and the resultant prose condensed into perhaps a paragraph or two, and potentially use ABNF for clarity: keypair = key [= value] key = 1*key_char key_char = %x20-%x3C / %x3E-%x7E value = *OCTET 6.5) I seem to have inadvertantly included much of this in my ABNF above in 6 characters. The last two paragraphs seem superfluous - specifications for debugging tools? 6.6) Describes the wire format, which strikes me as very much less than useful. Again, I've seen
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
On 4 Nov, 2008, at 07:50, Cyrus Daboo wrote: Hi, --On November 4, 2008 6:28:19 AM -0800 The IESG iesg- [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC The IANA section of the dns-sd draft describes a process for registration of SRV service identifiers, but there is another draft doing the same thing: http://www.ietf.org/internet-drafts/draft- gudmundsson-dns-srv-iana-registry-00.txt. So which of these two drafts is meant to define the actual SRV service type registry? -- Cyrus Daboo That text has been in DNS-SD since the start, back in 2001 when it was called Discovering Named Instances of Abstract Services using DNS (draft-cheshire-dnsext-nias-00.txt). I have absolutely no ego at stake over ownership of that issue -- I simply put it in because someone pointed out that RFC 2782 failed to define an IANA registry for its service names, and since DNS-SD/NIAS depends on SRV records and identifying service types by name instead of number, without an IANA registry the specification would be somewhat handicapped. Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Great document I really like it but I think there are a few things that need to be done to improve it on the administrative side (technically looks great).. First of all, it seems to me that there are lots of standards track stuff that will want to use this, it is well defined, works, widely implemented, and does not cause harm to existing things - Why would we do this as informations? I think it should be PS. Next, I think the IANA section needs some work. It seems that this specification needs to define a few registries. One for the application protocol names which needs to be somehow unified with ports, one for flagship names and another for the sub names. Perhaps there is a better way to organize these than 3 registries, I don't care how it gets done but it seems all three of these things do need to be registered. For the application protocol names, it seems wise for the registry to include things for each protocol such as 1) who registered it 2) optional associated specification such as RFC or URL 3) defined flags 4) associated flagship protocol 5) associated subs 7) full name of protocol. The IANA section should ideal provide a template used for new registrations. The specification should also provide the initial values to put in the registry. I would recommend include the 400+ names that are currently on the external site (thank you for running that BTW) in an appendix so they can be regressed. The IANA section should come into force on approval of draft, not on publication of RFC. This reduces the time of transition. IANA time is better spend not doing things like checking the protocol names meant the rules defined here. I think an expert review will do a better job of that. I think the registry should be Expert review from the beginning and this specification should provide guidance to the review that basically any name should be given on FCFS type basis as long as it meant the rules in this specification and was not making unreasonable use of the registry. This also resolves the issue of who and when could change it from FCFS to Expert Review. Would you b willing to be an expert reviewer for this? If the volume is high, some registries, such as ports have a bunch of reviewers. If we want to allow secret registrations, the exact details of that need to be provided here. I'm very against this as it would be an administrative nightmare to handle. Instead I would suggest a different process that achieves much the same effect. During secret product development, some random individual or even a agent who does not reveal who they are working for registers the protocol _dapp with no more information about that than who registered it. Later when the product is released, the agent or individual could transfer change control of the registration to apple and update the registration with all the other information including what dapp was an abbreviation for. This leads to another area, what to do when the person registered to update a registration can no longer be contacted at the supplied email address or easily found. In this case, I believe the expert should be able to update the registration up to and including removing it if there is a clear need to do that. Few other comments. The rest of my comments are small nits with the document. Some people may complain that you are using names other than example.* and use of such names in RFC may cause the internet to melt down. In section 4.2 seems to be the first mention of PTR records with no introductory text on how they are used or what they do. Seem like a sentence or two here might help. The PTR come up again in last para of section 8 but are not really explained until the next section. In section 6.5, I think you should soften the advice on using binary in the TXT records. Sure we need to keep record size in mind but for many cases, I can imagine an value containing an IP address to be much easier to work with in ascii than binary. [not to mention v6 address are sometimes smaller in binary than ascii]. I think the person defining the tags needs to carefully consider the representation keeping size limits in mind but ASCII is going to be easier to work with in many environments - particularly when using existing DNS servers and tools In section 12, it was not clear to me why and when you needed this. I suspect a little more motivation is needed here about what types of applications need to use these and when. Section 13.1 Given I would like this to wok with existing DNS servers, I think a MAY would be better than a SHOULD here. Or if you want to leave it as a SHOULD, explain when it is OK not to do this. Cullen in my individual contributor roll On Nov 4, 2008, at 7:28 , The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Hi, --On November 4, 2008 6:28:19 AM -0800 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC The IANA section of the dns-sd draft describes a process for registration of SRV service identifiers, but there is another draft doing the same thing: http://www.ietf.org/internet-drafts/draft-gudmundsson-dns-srv-iana-registry-00.txt. So which of these two drafts is meant to define the actual SRV service type registry? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-02. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns-sd-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=9784rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
