TSV-DIR review of draft-daboo-srv-caldav-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir@xxxxxxxx if you reply to or forward this review.

We would expect that the service names "caldev", "caldevs", "carddev", and "carddevs" would need to be registered in the SRV registry, which is being unified with the IANA ports registry as per pending BCP draft-ietf-tsvwg-iana-ports. None of these strings is registered in the current SRV registry. See the note #2 below.
The use of these strings inside the SRV records is consistent with the 
description in the pending BCP draft-ietf-tsvwg-iana-ports.
Some issues to discuss:

1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added.
2) the IANA recommendation that these four service names be added as 
aliases to http and https (correspondingly) does not seem correct. If 
these are indeed aliases, then this specification should recommend the 
use of either "http" or "https" (correspondingly) in the SRV records, 
without the need for new names. However, I believe the intent is that 
the caldev and/or carddev servers could exist on other ports than the 
typical web server; as such, they should be registered as service names 
(as per the existing SRV registry, e.g.), NOT as aliases in either the 
SRV registry (which has no such concept) or the IANA ports table.
I.e., these new names should be registered as service names, not as 
aliases. This should be sufficient for the purposes of this document.
3) The use of a required URI suffix (/carddev or /caldev) seems to be 
too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) 
indicates a way to embed this information in the a TXT record with the 
same DNS name as the SRV record;  RFC 5507 represents the IAB 
(informational) position that most additional information should be 
included in new RR types (though it's unclear this could easily support 
URI suffixes). My concern is that this document does neither; it embeds 
this information in this document as a requirement, rather than 
presenting it as a configurable option with a default. I would prefer to 
see the latter (regardless of how), to indicate the URI suffix if not 
the 'default' as specified in this document.
I don't see any other significant transport issues. It is always useful 
to note that short, multibyte transactions benefit from TCPs with Nagle 
disabled, but that is not a critical issue.
I'd be glad to discuss this further on whatever list would be useful.

Joe

---------------------

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]