The idea is interesting but there are LOTS of unanswered questions involved in using localized strings for identification. The NAME is there as a friendly/display name for the QUERY ("What the hell does QUERYID:Fizbin32 do??" vs "Ah, QUERYID:Fizbin32 is displayed w/the 'NAME:Fínd all calendars that Andrč owns'.") and not as part of searching for it.
(2) You can search for any component by ANY property value.
Are you proposing that we limit searching of VQUERYs to
be less than other components?> Even if it was suggested, there is NO prose in CAP _now_ for when NAME > is used, how it is to be used or when it is NOT used in conjunction > with QUERYID in a VQUERY. If (and thats a big if) the WG decides to > use NAME in addition to QUERYID as part of VQUERY location then issues > like dealing with specifying localization code pages used, etc need to > be answered.
(2) You can search for any component by ANY property value.
Are you proposing that we limit searching of VQUERYs to
be less than other components?By your removal and (so far) non responsiveness to your incorrect octet count conclusion, are you agreeing that it does indeed save one round trip and twice the stored VQUERY size in OCTETS at a minimum now so it is in fact 'efficient'?
Plus we use UID to uniqly identify several components. We use CSID to uniquly identify one type of component. We have a VQUERY component - are you proposing we have no unique way to store/fetch/modify/delete them?
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature