According to the reply from Erik Guttman (SLP WG Chair) to Bob
Herriot's comments below, the example where SLP attribute tags
(aka IPP attribute names) are translated when a template is
translated is WRONG. Only the attribute values are translated
(this would still mean that a German version of the template
would have German words for 'none', 'other', etc in the keyword
based attribute values specification in the template).
Please look over Bob's comments and Erik's replies.
Cheers,
- Ira McDonald
High North Inc
906-494-2434
--------------------------------------
Date: Wed, 28 Oct 1998 10:37:51 +0100
From: Erik Guttman <Erik.Guttman at Sun.COM>
Reply-To: Erik.Guttman at Sun.COM
Organization: Sun Microsystems
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: srvloc at srvloc.org
Subject: Re: comments on draft-ietf-svrloc-protocol-v2-09.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-srvloc at srvloc.org
Content-Transfer-Encoding: 7bit
Status: R
Robert,
My replies are interspersed.
Robert Herriot wrote:
>> The following are comments on draft-ietf-svrloc-protocol-v2-09.txt. I am not
> an expert in SLP, so I may have misunderstood parts of the draft. But I am
> the editor/author of some of the IPP drafts, so I am looking at SLP from the
> printing
> perspective.
>> Overall: it isn't clear whether all operations must support both unicast and
> multicast or whether only certain operations must support both. I suspect
> the latter and would suggest that there be a paragraph for each operation
> that
> states which it supports and under what conditions it expects them.
>
In draft 10 there is the clarification that DAs listen for unicast
requests except for multicast DA discovery. SAs listen for both
multicast requests *and* unicast requests and distinguish between
them using the MCAST RQST flag in the SLP Header.
> Section 2.1: The document says that a two-byte length field precedes all
> strings. It is not clear whether this refers generically to various length
> fields in the protocol or whether a string always includes a 2-byte length.
> If that is the case, then are integers considered to be strings for purposes
> of this encoding?
All attributes are encoded in strings.
The section you cite is an introductory section. Throughtout the spec
there are sections which are string encoded. They are always preceded
by a two byte length field.
>> Section 5: I have a concern about the syntax of a string governing the data
> type, particularly when the type affects the functionality, such as
> matching. If I understand the document correctly "1234" is an integer but
> "1234DM" and "12345678901" are both strings; "false" is a Boolean, but
> "falsehood" is a string. With wildcard matching as described in section 8.1
> "123*" would match the two strings in the previous example, but not the
> integer "1234", even though "123456787901" looks like an integer but is too
> big according to the syntax rules. It seems to me that everything should be
> a string or there should be some typing tag to specify type so that "1234"
> can be a string if that is what is intended. IPP, which is referenced by
> this document does it this latter way. I could see some potential problems
> if an
> admin puts the room number (e.g. "room 2345") into the IPP 'location'
> attribute (a string) for each printer, but puts only the room number for a
> few printers (e.g. "2585"). Then the SLP system has a string value for more
> "location" attributes, but an integer value for some.
>
This was a difficult design choice we made along the way. Without
including explicit typing in the attribute encoding or requiring the
use of service templates we had only 'implicit' typing rules available
at the time of evaluation of attributes.
It is indeed the case that an attribute value 2585 will not be
discoverable by asking "(location<=room 2600)" nor will the zip
code 34211 be discovered with "(zip code=342*)". The only way we
could have avoided this problem (besides adding explicit typing) is
to have gotten rid of integers all together (which itself is odd,
since 300 would be less than 9 lexically) or to say a query succeeds
if it is succeeds either lexically or for integers (which is ambiguous!)
The best solution is to use service templates which explicitely define
the types of attributes. Otherwise, integers together with inequality
search terms should be used with care.
> Section 6.4: Is it a good idea to do lexical ordering with UTF8 ordering?
> The ordering makes some sense in the ASCII subset and within some of the
> other alphabetic areas of UTF-8, but is not of much use with other
> characters. Also if SLP add other character set later, e.g. UTF-9, the
> results might be different. But the real question here is whether there is
> an important reason for needing < and >? Without < and >, the issue
> disappears except for character equivalence.
>
We won't add any character set later, we'll stick to the IESG recommendation
to use at least UTF8.
Ordering isn't trivial for UTF8, but it isn't REQUIRED in SLPv2.
I have a *very* small UTF8 string library I've written which handles
ordering for almost all code pages in UTF8 which humans use.
Removing LDAP <= and >= filter support would make SLPv2 incompatible
with the Search Filter specification which we don't want to do. If
there is significant WG agreement about this in the IESG last call we
*could* do this.
> Section 8.1: This section is an example of where important information is
> too distributed for easy comprehension. This section is not unique. The
> first paragraph says that scope (among others) must match in order for a
> service to match. I cannot find any text that says what happens when a
> "match" doesn't occur, but I infer that the receiver ignores the request in
> a broadcast and returns an error in a unicast. Paragraph 3 in this same
> section gives the hint for the unicast case, but is silent on the broadcast
> case.
You are correct: A failed match is dropped if multicast/broadcast,
and zero results (and possibly an error) are returned if unicast.
>> Section 8.1, second paragraph (PRList): I assume that this list should be
> empty for a unicast or perhaps could be ignored by a DA if it contains the
> name of the target DA. But the draft is silent in this case.
You are correct that it is empty if the request is unicast.
>> Section 8.1, second paragraph (PRList): The algorithm stops when the MTU is
> exceeded. What happens if there aren't enough accessible DA's to exceed the
> MTU?
>
Then the multicast convergence terminates after CONFIG_MC_MAX seconds.
This is explained in Section 6.3 "Retransmission of SLP messages."
> Section 8.1 next to last paragraph: The last sentence in this paragraph "The
> DA responds to this SrvRqst if the <scope-list> or <SLP SPI> string has been
> omitted" is unclear. The <SLP SPI> case is covered in the following
> paragraph and <scope-list> should be covered in the 3rd (scope-list)
> paragraph. Furthermore, this paragraph doesn't say what happens if both
> <scope-list> and <SLP SPI> are present.
>
You are right - this sentence doesn't add anything to the exposition
of the <scope-list> paragraph or the <SLP SPI> paragraph. Rather it
confuses them.
> Section 8.3 paragraph 2 typo: "MUST be contain" -> "MUST contain"
Check.
> Section 10.3: This operation looks like a unicast operation, but yet is has
> a PRList with no explanation except to see section 8.1. Is this correct?
>
This request, like SrvRqst and SrvTypeRqst may be multicast or unicast.
I see where the confusion lies. We tightened the language in the required
part of the draft so that it only cited SrvRqst in the list of requests
generated. This is so there would be no confusion that AttrRqst and
SrvTypeRqst must be implemented by UAs or SAs. What we need is a short
statement that SrvTypeRqsts and AttrRqsts are sent exactly as SrvRqsts.
In section 6.1. "Use of Ports, UDP, and Multicast" we mention how all
requests can be multicast or unicast, but it isn't enough to show the
reader that this includes SrvTypeRqst and AttrRqst messages.
> Section 16: Does having a separate set of attribute names for each language
> really work? Has someone thought through this proposal? In IPP, which will
> have to interface with SLP, our attribute names do not change with the
> language,
> though their values may. Instead we assume the existence of some other
> mapping software that converts IPP attribute names into human readable names
> in the appropriate language at the GUI level only.
We actually don't allow that in the Service Scheme document. The fact that
example in section 10.4 indicates this is an error. Section 16 should be
explicit that attribute tags are not translated, though attribute values
are. Please see the Service Scheme document for details how this is done.
In summary I found points that require modification in a subsequent draft
of the SLPv2 specification:
(1) remove a confusing sentence from section 8.1.
"The DA responds to this SrvRqst if the <scope-list> or
<SLP SPI> string has been omitted"
(2) remove a typographic error from section 8.3.
"MUST be contain" -> "MUST contain"
(3) add to Section 3. "Protocol Overview" that SrvTypeRqst and AttrRqst
are sent as SrvRqst (either unicast or multicast)
(4) add a clarification to section 6.1 "Unicast..." that unicast requests
contain an empty PR list.
(5) fix the example in section 10.4 and make explicit in section 16 that
attribute tags are NOT translated, only attribute values.
Thanks for your careful review of the internet draft,
Erik