On Wed, Jun 17, 2020 at 01:23:45PM +0000, Hollenbeck, Scott wrote:
> From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
>> 5) Section 4.4 - The following sentence seems to be inconsistent
>> with the content of some figures (e.g. Fig. 15, 17, 23, ...) where
>> a "lang" element is included in jCard
>>
>> The "lang" attribute may appear anywhere in an object class or data
>> structure except for in jCard objects.
>
> [SAH] Agreed. I'll strike "except for in jCard objects".
The motivation for including "except in jCard objects" originally was
to make it clear that an implementor couldn't include the lang
attribute as defined in this section in a jCard object. To preserve
that aspect while making it clear that the language-related content
defined in jCard may be used, I think the following would work better:
The "lang" attribute as defined in this section may appear
anywhere in an object class or data structure, except for in jCard
objects. To avoid any doubt, language-related tags and parameters
defined by jCard itself may be used in jCard objects.
though the wording is a little awkward.
>> 7) Section 10.2.3 - The definition of "last changed" event type
>> seems to be inconsistent with "upDate" defined in RFC
>> 5731,5732,5733. For example, I report an extract from RFC5731 here
>> in the following:
>>
>> - An OPTIONAL <domain:upDate> element that contains the date and
>> time of the most recent domain-object modification. This element
>> MUST NOT be present if the domain object has never been modified.
>>
>> So, should we redefine the "last changed" event accordingly? Should
>> we change all the examples where "last changed" date is equal to
>> "registration" date?
>
> [SAH] I think we can leave this one alone. The meaning seems clear
> to me since we also have the registration event. We could change the
> examples, but before I do that I'd like to know what people have
> implemented. Do servers return this value for an object that has
> been registered, but never updated?
We return this value for objects that have been registered, but not
updated, mainly because distinguishing these two dates in our systems
for some objects is non-trivial. I think the current text supports
this approach, even given the presence of the 'registration' event
type (and regardless of whether those events are included in the
response), and that the current text is fine. (We do intend to
include 'registration' events at some point, and would prefer to
continue including 'last changed' events alongside them even when the
values are the same, so that things continue to work as they did
previously for existing clients.)
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
