LDAP Extension (ldapext)

headers Kurt Zeilenga | 20 Oct 2010 15:20

_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

I don't have a problem with any of the names requested in that they
don't clash with anything I'm aware of. However, a name like "provider"
is fairly generic and might clash with someone's local definition.
I would suggest prefixing all the names with "pec" to reduce the chance
of conflict (so pecProvider, pecProviderCertificateHash, etc.).

Regards,
Steven

On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
> Any comments? If so, please direct them to directory <at> apps.ietf.org
> <mailto:directory <at> apps.ietf.org>.
>
> -- Kurt
>
> Begin forwarded message:
>
>> *From: *Alba Shahin <alba.shahin <at> isti.cnr.it
>> <mailto:alba.shahin <at> isti.cnr.it>>
>> *Date: *October 4, 2010 8:37:48 AM PDT
>> *To: *directory <at> apps.ietf.org <mailto:directory <at> apps.ietf.org>
>> *Cc: *Sean Turner <turners <at> ieca.com <mailto:turners <at> ieca.com>>, "Polk,
>> William T." <william.polk <at> nist.gov <mailto:william.polk <at> nist.gov>>,
>> draft-gennai-smime-cnipa-pec <at> tools.ietf.org
>> <mailto:draft-gennai-smime-cnipa-pec <at> tools.ietf.org>
>> *Subject: **Request for LDAP expert review of PEC object identifier
>> descriptors*
>> *x-spam-score: *1.882
>> *x-spam-status: *No, score=1.882 tagged_above=-999 required=5
>> tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245,
>> HTML_MESSAGE=0.001]
>> *list-id: *Discussion of issues related to directories
>> <directory.ietf.org <http://directory.ietf.org>>
>>
>> Hello,
>> We would like to request an expert review of the LDAP object
>> identifier descriptors defined in PEC (Italian Certified Electronic Mail)
>> [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] and
>> pasted below.
>> (Some minor changes were made below wrt what’s in the draft).
>> We look forward to your feedback on this.
>> Thank you.
>> --Alba
>> ----
>> 8.2.1. Registration of Object Classes
>> Subject: Request for LDAP Descriptor Registration
>> Descriptor (short name): See comments
>> Object Identifier: See comments
>> Person & email address to contact for further information:
>> See "Author/Change Controller"
>> Usage: object class
>> Specification: (I-D)
>> Author/Change Controller:
>> Claudio Petrucci
>> DigitPA
>> Viale Carlo Marx 31/49
>> 00137 Roma
>> Italy
>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>> Comments:
>> The following object identifiers and associated object classes
>> are requested to be registered.
>> OID Object Class
>> ------------------------- -----------------------
>> 1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject
>> 1.3.6.1.4.1.16572.2.1.2 provider
>> Please also see the associated registration request for the
>> providerCertificateHash, providerCertificate, providerName,
>> mailReceipt, managedDomains, LDIFLocationURL, and providerUnit
>> attribute types.
>> 8.2.2. Registration of Attribute Types
>> Subject: Request for LDAP Descriptor Registration
>> Descriptor (short name): See comments
>> Object Identifier: See comments
>> Person & email address to contact for further information:
>> See "Author/Change Controller"
>> Usage: attribute type
>> Specification: (I-D)
>> Author/Change Controller:
>> Claudio Petrucci
>> DigitPA
>> Viale Carlo Marx 31/49
>> 00137 Roma
>> Italy
>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>> Comments:
>> The following object identifiers and associated attribute types
>> are requested to be registered.
>> OID Attribute Type
>> ------------------------- -------------------------
>> 1.3.6.1.4.1.16572.2.2.1 providerCertificateHash
>> 1.3.6.1.4.1.16572.2.2.2 providerCertificate
>> 1.3.6.1.4.1.16572.2.2.3 providerName
>> 1.3.6.1.4.1.16572.2.2.4 mailReceipt
>> 1.3.6.1.4.1.16572.2.2.5 managedDomains
>> 1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL
>> 1.3.6.1.4.1.16572.2.2.7 providerUnit
>> Please also see the associated registration request for the
>> LDIFLocationURLObject and provider object classes.
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

Hello,
    A new version of the draft 
(http://tools.ietf.org/html/draft-cal-resource-schema-02), describing 
the schema for representing resources for calendaring and scheduling 
based on our discussions in Calconnect, has been submitted. This draft 
includes a mapping of the schema for both vCard and LDAP. We have tried 
to reuse existing LDAP attributes as much as possible.

   I would really appreciate review and feedback by the experts.

Thanks,
Ciny

Hello Steven.

Thank you for the comment. We agree that adding a "pec" prefix would make
certain values less prone to misunderstandings, but we'd like to point out
that there are currently several functioning implementations that use the
values as defined in the draft. If possible we would like said draft to be
representative of how things are right now, therefore maintain the values
that are being used by those existing implementations.
We think they should be unambiguous in any case, since those values are
defined within the PEC context under the PEC tree.

Do you think keeping the values as they are now is possible?

Regards,
--Alba

-----Original Message-----
From: Steven Legg [mailto:steven.legg <at> eNitiatives.com.au] 
Sent: giovedì 21 ottobre 2010 01:22
To: directory <at> apps.ietf.org; alba.shahin <at> isti.cnr.it
Cc: Kurt Zeilenga; ldapext <at> ietf.org
Subject: Re: [ldapext] Fwd: Request for LDAP expert review of PEC object
identifier descriptors

I don't have a problem with any of the names requested in that they don't
clash with anything I'm aware of. However, a name like "provider"
is fairly generic and might clash with someone's local definition.
I would suggest prefixing all the names with "pec" to reduce the chance of
conflict (so pecProvider, pecProviderCertificateHash, etc.).

Regards,
Steven

On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
> Any comments? If so, please direct them to directory <at> apps.ietf.org 
> <mailto:directory <at> apps.ietf.org>.
>
> -- Kurt
>
> Begin forwarded message:
>
>> *From: *Alba Shahin <alba.shahin <at> isti.cnr.it 
>> <mailto:alba.shahin <at> isti.cnr.it>>
>> *Date: *October 4, 2010 8:37:48 AM PDT
>> *To: *directory <at> apps.ietf.org <mailto:directory <at> apps.ietf.org>
>> *Cc: *Sean Turner <turners <at> ieca.com <mailto:turners <at> ieca.com>>, 
>> "Polk, William T." <william.polk <at> nist.gov 
>> <mailto:william.polk <at> nist.gov>>, 
>> draft-gennai-smime-cnipa-pec <at> tools.ietf.org
>> <mailto:draft-gennai-smime-cnipa-pec <at> tools.ietf.org>
>> *Subject: **Request for LDAP expert review of PEC object identifier
>> descriptors*
>> *x-spam-score: *1.882
>> *x-spam-status: *No, score=1.882 tagged_above=-999 required=5 
>> tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 
>> HTML_MESSAGE=0.001]
>> *list-id: *Discussion of issues related to directories 
>> <directory.ietf.org <http://directory.ietf.org>>
>>
>> Hello,
>> We would like to request an expert review of the LDAP object 
>> identifier descriptors defined in PEC (Italian Certified Electronic 
>> Mail) [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] 
>> and pasted below.
>> (Some minor changes were made below wrt whats in the draft).
>> We look forward to your feedback on this.
>> Thank you.
>> --Alba
>> ----
>> 8.2.1. Registration of Object Classes
>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>> name): See comments Object Identifier: See comments Person & email 
>> address to contact for further information:
>> See "Author/Change Controller"
>> Usage: object class
>> Specification: (I-D)
>> Author/Change Controller:
>> Claudio Petrucci
>> DigitPA
>> Viale Carlo Marx 31/49
>> 00137 Roma
>> Italy
>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>> Comments:
>> The following object identifiers and associated object classes are 
>> requested to be registered.
>> OID Object Class
>> ------------------------- -----------------------
>> 1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject
>> 1.3.6.1.4.1.16572.2.1.2 provider
>> Please also see the associated registration request for the 
>> providerCertificateHash, providerCertificate, providerName, 
>> mailReceipt, managedDomains, LDIFLocationURL, and providerUnit 
>> attribute types.
>> 8.2.2. Registration of Attribute Types
>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>> name): See comments Object Identifier: See comments Person & email 
>> address to contact for further information:
>> See "Author/Change Controller"
>> Usage: attribute type
>> Specification: (I-D)
>> Author/Change Controller:
>> Claudio Petrucci
>> DigitPA
>> Viale Carlo Marx 31/49
>> 00137 Roma
>> Italy
>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>> Comments:
>> The following object identifiers and associated attribute types are 
>> requested to be registered.
>> OID Attribute Type
>> ------------------------- -------------------------
>> 1.3.6.1.4.1.16572.2.2.1 providerCertificateHash
>> 1.3.6.1.4.1.16572.2.2.2 providerCertificate
>> 1.3.6.1.4.1.16572.2.2.3 providerName
>> 1.3.6.1.4.1.16572.2.2.4 mailReceipt
>> 1.3.6.1.4.1.16572.2.2.5 managedDomains
>> 1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL
>> 1.3.6.1.4.1.16572.2.2.7 providerUnit
>> Please also see the associated registration request for the 
>> LDIFLocationURLObject and provider object classes.
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

Alba,

First, I like to note that this 'LDAP expert review' is limited, per BCP 64, to the registration requests, as
well as the use of non-registered protocol values (see below).  It's not a review of your technical
specification.  However, it's hard for me not to comment on a few obvious technical issues I found by quick
scan of this document.  Hence, I will separately send a few technical comments separately (with my IANA
"LDAP expert review" hat off).

While the I-D's 8.2 is properly titled 'Registration of LDAP object identifier descriptors', the
subsections 8.2.1 and 8.2.2 incorrectly request LDAP OID registration.  This caused some confusion at
IANA.  While it fine to use a table to avoid having 9 separate templates, there is no need to have two tables of
descriptors.  Using one table, of the form of the "Object Identifier Descriptors" registry in the IANA
ldap-parameter file <http://www.iana.org/assignments/ldap-parameters> would be better (both less
confusing and easier on IANA (they could just cut-n-paste)).  Please update the I-D to have a single
table-based registration request for all 9 requested descriptors.

Like Steve, I generally prefer that descriptor values be more specific and relate more clearly to the
application they are designed for.  As Steven suggests, prefixing everything with 'pec' would generally
be appropriate.

I do understand the desire of not wanting to require existing implementations to change.  I think here one
has to balance the possibility of future real world conflicts, which will require some implementations
(PECs or the conflicting ones) to change to co-exist.   Registration with IANA may well aide PECs to "win"
such conflicts.   However, so long as the community understands the possibility of such conflicts, and
knowing PECs might not win in the real world despite being registered, I don't object to registration of
these descriptors as requested.  (The two I am most concerned about are 'provider' and 'mailReceipt'.)

Hence, I, as the assigned LDAP registration "expert", tentatively approve the registration of these 9
descriptors pending update of the IANA consideration section as discussed above, such registration to
be made by IANA just prior to publication as an RFC.  Upon update, please notify me so that I can take
appropriate action (e.g., notify IANA that all is well).

However, if for any reason the schema were to change (such as due to late comments , I strongly advise
injecting a 'pec' prefix into every descriptor.

Lastly, I note the I-D suggests the use of naming context named "o=postacert" but no where details how this
name was properly delegated for the purposes discussed in the I-D.   Presumedly this is because it's not
properly delegated.  Traditionally, LDAP relies on X.500 delegation or DNS-based name delegation.  That
is, names properly delegated in X.500 or DNS, each by an appropriate naming authority, are usable in LDAP
(via mechanical translation) without the need for any further registration requirement.  
Traditionally, top level naming contexts of type o (organization) have been unregulated.  However, this
may change in the future due to the popularity of top-level organization naming.

While "o=portacert" is not registrable (at this time), one could registered a domain namefor this purpose
of use in constructing an LDAP DN.  (If the authors want to pursue this approach, I would suggest bringing in
a DNS expert.*)  If the authors wish to continue to use "o=postacert", I recommend an IESG note be added that
this specification utilized unregistered LDAP DN name space which may lead to conflict with other
registered or unregistered names.

Regards, Kurt

(* At first, I was thinking of a domain under .arpa could be used, but it seems that this purpose likely met the
requirements for .arpa delegation).

On Oct 22, 2010, at 4:01 AM, Alba Shahin wrote:

> Hello Steven.
> 
> Thank you for the comment. We agree that adding a "pec" prefix would make
> certain values less prone to misunderstandings, but we'd like to point out
> that there are currently several functioning implementations that use the
> values as defined in the draft. If possible we would like said draft to be
> representative of how things are right now, therefore maintain the values
> that are being used by those existing implementations.
> We think they should be unambiguous in any case, since those values are
> defined within the PEC context under the PEC tree.
> 
> Do you think keeping the values as they are now is possible?
> 
> Regards,
> --Alba
> 
> 
> 
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg <at> eNitiatives.com.au] 
> Sent: giovedì 21 ottobre 2010 01:22
> To: directory <at> apps.ietf.org; alba.shahin <at> isti.cnr.it
> Cc: Kurt Zeilenga; ldapext <at> ietf.org
> Subject: Re: [ldapext] Fwd: Request for LDAP expert review of PEC object
> identifier descriptors
> 
> 
> I don't have a problem with any of the names requested in that they don't
> clash with anything I'm aware of. However, a name like "provider"
> is fairly generic and might clash with someone's local definition.
> I would suggest prefixing all the names with "pec" to reduce the chance of
> conflict (so pecProvider, pecProviderCertificateHash, etc.).
> 
> Regards,
> Steven
> 
> On 21/10/2010 12:20 AM, Kurt Zeilenga wrote:
>> Any comments? If so, please direct them to directory <at> apps.ietf.org 
>> <mailto:directory <at> apps.ietf.org>.
>> 
>> -- Kurt
>> 
>> Begin forwarded message:
>> 
>>> *From: *Alba Shahin <alba.shahin <at> isti.cnr.it 
>>> <mailto:alba.shahin <at> isti.cnr.it>>
>>> *Date: *October 4, 2010 8:37:48 AM PDT
>>> *To: *directory <at> apps.ietf.org <mailto:directory <at> apps.ietf.org>
>>> *Cc: *Sean Turner <turners <at> ieca.com <mailto:turners <at> ieca.com>>, 
>>> "Polk, William T." <william.polk <at> nist.gov 
>>> <mailto:william.polk <at> nist.gov>>, 
>>> draft-gennai-smime-cnipa-pec <at> tools.ietf.org
>>> <mailto:draft-gennai-smime-cnipa-pec <at> tools.ietf.org>
>>> *Subject: **Request for LDAP expert review of PEC object identifier
>>> descriptors*
>>> *x-spam-score: *1.882
>>> *x-spam-status: *No, score=1.882 tagged_above=-999 required=5 
>>> tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 
>>> HTML_MESSAGE=0.001]
>>> *list-id: *Discussion of issues related to directories 
>>> <directory.ietf.org <http://directory.ietf.org>>
>>> 
>>> Hello,
>>> We would like to request an expert review of the LDAP object 
>>> identifier descriptors defined in PEC (Italian Certified Electronic 
>>> Mail) [http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt] 
>>> and pasted below.
>>> (Some minor changes were made below wrt what’s in the draft).
>>> We look forward to your feedback on this.
>>> Thank you.
>>> --Alba
>>> ----
>>> 8.2.1. Registration of Object Classes
>>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>>> name): See comments Object Identifier: See comments Person & email 
>>> address to contact for further information:
>>> See "Author/Change Controller"
>>> Usage: object class
>>> Specification: (I-D)
>>> Author/Change Controller:
>>> Claudio Petrucci
>>> DigitPA
>>> Viale Carlo Marx 31/49
>>> 00137 Roma
>>> Italy
>>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>>> Comments:
>>> The following object identifiers and associated object classes are 
>>> requested to be registered.
>>> OID Object Class
>>> ------------------------- -----------------------
>>> 1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject
>>> 1.3.6.1.4.1.16572.2.1.2 provider
>>> Please also see the associated registration request for the 
>>> providerCertificateHash, providerCertificate, providerName, 
>>> mailReceipt, managedDomains, LDIFLocationURL, and providerUnit 
>>> attribute types.
>>> 8.2.2. Registration of Attribute Types
>>> Subject: Request for LDAP Descriptor Registration Descriptor (short 
>>> name): See comments Object Identifier: See comments Person & email 
>>> address to contact for further information:
>>> See "Author/Change Controller"
>>> Usage: attribute type
>>> Specification: (I-D)
>>> Author/Change Controller:
>>> Claudio Petrucci
>>> DigitPA
>>> Viale Carlo Marx 31/49
>>> 00137 Roma
>>> Italy
>>> EMail:PETRUCCI <at> digitpa.gov.it <mailto:PETRUCCI <at> digitpa.gov.it>
>>> Comments:
>>> The following object identifiers and associated attribute types are 
>>> requested to be registered.
>>> OID Attribute Type
>>> ------------------------- -------------------------
>>> 1.3.6.1.4.1.16572.2.2.1 providerCertificateHash
>>> 1.3.6.1.4.1.16572.2.2.2 providerCertificate
>>> 1.3.6.1.4.1.16572.2.2.3 providerName
>>> 1.3.6.1.4.1.16572.2.2.4 mailReceipt
>>> 1.3.6.1.4.1.16572.2.2.5 managedDomains
>>> 1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL
>>> 1.3.6.1.4.1.16572.2.2.7 providerUnit
>>> Please also see the associated registration request for the 
>>> LDIFLocationURLObject and provider object classes.
>> 
>> 
>> 
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ldapext
> 
I did not become aware of this I-D and its use of LDAP until recently.  Here is a quick review.  It's quick in that
I didn't try to understand the application the schema is intended to support, just looked at the LDAP bits.

I don't understand the use of naming context "o=postacert".   The use of hardcoded DN seems bad to me, and it's
unregistered as well.  It's unclear whether each deployment of an implementation of this specification
is required to use this context.  If so, that seems problematic.  It would, for instance, preclude two
deployments from sharing the same directory system.

The specification includes DN strings, such as "providerName=<name>, o=postacert", which do not
conform to LDAP DN.  It is recommend that DNs in RFCs be presented as discussed in LDAP DN, e.g <providerName=<name>,o=postacert>.

It is odd and somewhat problematic to match a hash via case-sensitive matching, and to store it as a
hexadecimal string.  The specification doesn't actually state what it means by 'hexadecimal'.  There
many ways to write hexadecimal, and certainly case-sensitive matching isn't going to all hexadecimal
representations of a particular hash value as equivalent.  It would be fare better to store the actual hash
as an octet string and do octet wise matching, that is, providerCertificateHash should have syntax
octetString and equality rule octetStringMatch.  This avoid unnecessary hex encoding/decoding in implementations.

And storing and search for a hash here seems quite odd to me.  It's would seem better to just search for the certificate.

Note that {40} in 1.3.6.1.4.1.1466.115.121.1.26{40} does not define a maximum length.  It basically
extraneous in LDAPv3 (see the LDAP "models" RFC).

The specification of providerCertificate references RFC 2252, which was obsoleted.  The specification
of the certificate syntax is now in RFC 4523.  Note that that ;binary MUST, per RFC 4523, be used with
providerCertificate.  The specification should echo this require (use the same language used in the
specification of userCertificate, see RFC 4523).  Also note that the certificate syntax is NOT
restricted to DER.

The draft contains a note about the deprecation of the binary syntax.  Given the document doesn't use the
binary syntax, this is extraneous at best.  It seems the authors may have confused ;binary transfer should
not be confused with the binary syntax.  ;binary transfer is detailed in RFC 4522, and as noted above, MUST
be used when requesting and transferring values the certificate syntax.

mailReceipt spec should discuss IDNA and EAI.  And {256} is extraneous.

managedDomains spec should discuss IDNA.

providerUnit contains a {32768} which is extraneous.

No LDAP object class descriptions is provided for LDIFLocationURLObject or provider classes, or if what
is provided was intended to be an LDAP object class description, it doesn't conform to object class
description syntax.

Regarding the LDIFLocationURL, the document likely ought to say something about the MIME type, character
set encoding, etc., of the document to returned by the URL.

-- Kurt

LDAPext'ers,

Please review.

Ciny,

Your I-D should contain appropriate registration requests for all the new LDAP descriptors defined in the
document, and the registration request submitted for consideration as discussed in BCP 64.

-- Kurt

On Oct 21, 2010, at 9:58 AM, Ciny Joy wrote:

> Hello,
>   A new version of the draft (http://tools.ietf.org/html/draft-cal-resource-schema-02), describing
the schema for representing resources for calendaring and scheduling based on our discussions in
Calconnect, has been submitted. This draft includes a mapping of the schema for both vCard and LDAP. We
have tried to reuse existing LDAP attributes as much as possible.
> 
>  I would really appreciate review and feedback by the experts.
> 
> Thanks,
> Ciny

Hello Kurt,
    Thank you so much for the response. I will look into doing the 
registration as described in BCP 64. Wondering if it would be prudent to 
wait for any issues that might come up during reviews before doing that.

Thanks,
Ciny

On 10/24/10 2:36 PM, Kurt Zeilenga wrote:
> LDAPext'ers,
>
> Please review.
>
> Ciny,
>
> Your I-D should contain appropriate registration requests for all the new LDAP descriptors defined in
the document, and the registration request submitted for consideration as discussed in BCP 64.
>
> -- Kurt
>
> On Oct 21, 2010, at 9:58 AM, Ciny Joy wrote:
>
>> Hello,
>>    A new version of the draft (http://tools.ietf.org/html/draft-cal-resource-schema-02),
describing the schema for representing resources for calendaring and scheduling based on our
discussions in Calconnect, has been submitted. This draft includes a mapping of the schema for both vCard
and LDAP. We have tried to reuse existing LDAP attributes as much as possible.
>>
>>   I would really appreciate review and feedback by the experts.
>>
>> Thanks,
>> Ciny
>

On 10/24/10 4:34 PM, Kurt Zeilenga wrote:

> mailReceipt spec should discuss IDNA and EAI.

Wouldn't referring to [SMTP] (RFC 5322) suffice?

OLD:

The 'mailReceipt' attribute contains the provider's email address to 
which take in charge and virus detection PEC notifications are sent.

NEW:

The 'mailReceipt' attribute contains the provider's email address 
[SMTP] to which take in charge and virus detection PEC notifications 
are sent.

> managedDomains spec should discuss IDNA.

Ditto:

OLD:

The 'managedDomains' attribute lists the PEC domains that are handled 
by the provider.

NEW:

The 'managedDomains' attribute lists the PEC domains [SMTP] that are 
handled by the provider.

spt

On Oct 26, 2010, at 6:08 PM, Sean Turner wrote:

> On 10/24/10 4:34 PM, Kurt Zeilenga wrote:
> 
>> mailReceipt spec should discuss IDNA and EAI.
> 
> Wouldn't referring to [SMTP] (RFC 5322) suffice?

Personally, I would prefer a bit more precise statement.  For instance, is it an <address> or some subset of
<address>, like <addr-spec>?

But given this is only to be published as Informational, I don't mind too much the lack of precision.

> 
> OLD:
> 
> The 'mailReceipt' attribute contains the provider's email address to which take in charge and virus
detection PEC notifications are sent.
> 
> NEW:
> 
> The 'mailReceipt' attribute contains the provider's email address [SMTP] to which take in charge and
virus detection PEC notifications are sent.
> 
>> managedDomains spec should discuss IDNA.
> 
> Ditto:
> 
> OLD:
> 
> The 'managedDomains' attribute lists the PEC domains that are handled by the provider.
> 
> NEW:
> 
> The 'managedDomains' attribute lists the PEC domains [SMTP] that are handled by the provider.

I rather not use the verb "lists" as an attribute holds a set of values (not a sequence).  The placement of PEC
seems begs the question "what's a PEC domain?".  I think what's actually meant is:
	The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider.

Note that RFC 5322's domain actually allows values such as [127.0.0.1].  It's not clear such values make
sense here.

> 
> spt

1	April 2013
10	March 2013
13	January 2013
4	December 2012
2	April 2012
2	November 2011
9	July 2011
4	April 2011
2	December 2010
1	November 2010
10	October 2010
1	September 2010
4	August 2010
39	July 2010
9	June 2010
8	May 2010
10	April 2010
2	March 2010
1	January 2010
1	December 2009
2	November 2009
6	October 2009
2	September 2009
17	August 2009
6	July 2009
49	June 2009
2	May 2009
6	April 2009
18	March 2009
1	February 2009
1	January 2009
17	December 2008
24	November 2008
1	October 2008
19	September 2008
3	August 2008
11	July 2008
1	June 2008
15	April 2008
2	March 2008
7	February 2008
10	January 2008
1	December 2007
3	October 2007
87	September 2007
2	August 2007
6	June 2007
8	May 2007
1	April 2007
51	February 2007
2	January 2007
7	November 2006
3	October 2006
4	August 2006
1	July 2006
4	June 2006
19	May 2006
18	March 2006
9	February 2006
18	January 2006
2	December 2005
4	November 2005
7	October 2005
4	September 2005
6	August 2005
11	July 2005
10	June 2005
1	May 2005
32	April 2005
36	February 2005
7	January 2005
9	December 2004
49	November 2004
68	October 2004
40	September 2004
19	August 2004
13	July 2004
71	June 2004
29	May 2004
27	April 2004
41	March 2004
10	February 2004
8	January 2004
14	December 2003
34	November 2003
21	October 2003
10	September 2003
5	August 2003
35	July 2003
8	June 2003
32	May 2003
29	April 2003
15	March 2003
27	February 2003
13	December 2002
26	November 2002
40	October 2002
51	September 2002
51	August 2002
4	July 2002
2	June 2002
29	May 2002
8	April 2002

Fwd: Request for LDAP expert review of PEC object identifier descriptors

Re: Fwd: Request for LDAP expert review of PEC object identifier descriptors

Request for review draft-cal-resource-schema - Schema for representing resources for calendaring and scheduling services

Re: Fwd: Request for LDAP expert review of PEC object identifier descriptors

Re: Request for LDAP expert review of PEC object identifier descriptors

Review of draft-gennai-smime-cnipa-pec-08.txt

Re: Request for review draft-cal-resource-schema - Schema for representing resources for calendaring and scheduling services

Re: Request for review draft-cal-resource-schema - Schema for representing resources for calendaring and scheduling services

Re: Review of draft-gennai-smime-cnipa-pec-08.txt

Re: Review of draft-gennai-smime-cnipa-pec-08.txt

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31