RE: Contact Client ID Namespace Management

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Friday, April 19, 2002 6:01 AM
> To: Ietf-Provreg (E-mail)
> Subject: Contact Client ID Namespace Management
> 
> 
> Sources :
> draft-ietf-provreg-epp-06.txt
> draft-ietf-provreg-epp-contact-04.txt
> 
> According to the contacts specification, page 17:
> 
>   ...  
>   A <contact:id> element that contains the desired server-unique
>   identifier for the contact to be created.
>   ...
> 
> <contact:id> values are server(registry)-unique but
> client(registrar)-created. It would seem reasonable to partition the
> possible values of <contact:id> among the various contacts so 
> as to reduce
> the possibility of name collisions on creation of new 
> contacts. This would
> be a matter of server policy. One possible scheme would be to 
> allocate a 4
> character prefix to each registrar, and allow the registrar 
> to allocate
> their own 12-character suffix. Doing so would allow each 
> registrar to manage
> a subset of the complete namespace without too much overhead.

Your suggestion is based on the (possibly false) premises that the IDs
should always be client-created and that the registry-registrar model is the
only one at work.  My thought going in was that the IDs would in fact be
end-user suggested in a manner similar to the way many 'net services (think
ebay, yahoo, etc.) allow individuals to create their own user IDs, and the
client would act as agent in an attempt to create the ID with the server.
Some domain name registrars might be doing it differently, but that doesn't
mean that the protocol should be limited to supporting such a model.

> If we adopt this scheme, or a similar one, there's nothing in 
> EPP itself to
> prevent one client using identifiers from another client's 
> subset of the
> contact:id values. Would it be reasonable for a server to 
> maintain allowed
> prefixes each client, and validate incoming <contact:create> 
> commands to
> ensure that <contact:id> fields match allowed values? Again 
> this would be a
> matter of service policy?
> 
> Any thoughts on the above would be appreciated.

I'd prefer to keep this sort of policy model out of the specs completely.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3MDmUTB019930 for <[e-mail]>; Mon, 22 Apr 2002 15:48:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3MDmU1t019929 for ietf-provreg-outgoing; Mon, 22 Apr 2002 15:48:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3MDmSTB019924 for <[e-mail]>; Mon, 22 Apr 2002 15:48:29 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA11170; Mon, 22 Apr 2002 09:28:14 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF5VYAW>; Mon, 22 Apr 2002 09:48:26 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Contact Client ID Namespace Management
Date: Mon, 22 Apr 2002 09:48:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Friday, April 19, 2002 6:01 AM
> To: Ietf-Provreg (E-mail)
> Subject: Contact Client ID Namespace Management
> 
> 
> Sources :
> draft-ietf-provreg-epp-06.txt
> draft-ietf-provreg-epp-contact-04.txt
> 
> According to the contacts specification, page 17:
> 
>   ...  
>   A <contact:id> element that contains the desired server-unique
>   identifier for the contact to be created.
>   ...
> 
> <contact:id> values are server(registry)-unique but
> client(registrar)-created. It would seem reasonable to partition the
> possible values of <contact:id> among the various contacts so 
> as to reduce
> the possibility of name collisions on creation of new 
> contacts. This would
> be a matter of server policy. One possible scheme would be to 
> allocate a 4
> character prefix to each registrar, and allow the registrar 
> to allocate
> their own 12-character suffix. Doing so would allow each 
> registrar to manage
> a subset of the complete namespace without too much overhead.

Your suggestion is based on the (possibly false) premises that the IDs
should always be client-created and that the registry-registrar model is the
only one at work.  My thought going in was that the IDs would in fact be
end-user suggested in a manner similar to the way many 'net services (think
ebay, yahoo, etc.) allow individuals to create their own user IDs, and the
client would act as agent in an attempt to create the ID with the server.
Some domain name registrars might be doing it differently, but that doesn't
mean that the protocol should be limited to supporting such a model.

> If we adopt this scheme, or a similar one, there's nothing in 
> EPP itself to
> prevent one client using identifiers from another client's 
> subset of the
> contact:id values. Would it be reasonable for a server to 
> maintain allowed
> prefixes each client, and validate incoming <contact:create> 
> commands to
> ensure that <contact:id> fields match allowed values? Again 
> this would be a
> matter of service policy?
> 
> Any thoughts on the above would be appreciated.

I'd prefer to keep this sort of policy model out of the specs completely.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3MDXwTB019835 for <[e-mail]>; Mon, 22 Apr 2002 15:33:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3MDXwMT019834 for ietf-provreg-outgoing; Mon, 22 Apr 2002 15:33:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3MDXsTB019829 for <[e-mail]>; Mon, 22 Apr 2002 15:33:57 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA10424; Mon, 22 Apr 2002 09:13:34 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQ611Q>; Mon, 22 Apr 2002 09:33:46 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: <postalInfo> element in contact management
Date: Mon, 22 Apr 2002 09:33:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Friday, April 19, 2002 5:39 AM
> To: Ietf-Provreg (E-mail)
> Subject: <postalInfo> element in contact management
> 
> 
> Source :draft-ietf-provreg-epp-contact-04.txt
> 
> Quote from the <contact:info> command page 11
>   ... 
>   One or two <contact:postalInfo> elements that contain postal address
>   information.  Two elements are provided so that address information
>   can be provided in both internationalized and localized 
> forms.  If an
>   internationalized form is provided, it MUST be listed first and
>   element content MUST be represented in a subset of UTF-8 that can be
>   represented in the 7-bit US-ASCII character set.  If a 
> localized form
>   is provided, element content MAY be represented in 
> unrestricted UTF-8.
>   ...
> 
> If two <contact:postalInfo> elements are provided the above 
> paragraph makes
> it clear which one is the internationalized form and which is 
> the localized
> form. However, if only one <contact:postalInfo> element is 
> supplied, is it
> understood to be internationalized or localized?

That depends on the characters used.  If characters outside the ASCII range
are used, you have something that's localized.  ASCII only ->
internationalized.  This might be more clear if we add an attribute to the
<postalInfo> element; at least it would allow one to decide without having
to examine all of the data directly.

Disclaimer: again, we're still waiting for IESG feedback on the last call.
I can't change anything easily at this point, though I will queue this idea
for discussion with the IESG when they get back to us with comments.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3JA0wTB005303 for <[e-mail]>; Fri, 19 Apr 2002 12:00:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3JA0wjJ005302 for ietf-provreg-outgoing; Fri, 19 Apr 2002 12:00:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3JA0vTB005297 for <[e-mail]>; Fri, 19 Apr 2002 12:00:57 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <20RK2JF6>; Fri, 19 Apr 2002 11:00:56 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Contact Client ID Namespace Management
Date: Fri, 19 Apr 2002 11:00:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sources :
draft-ietf-provreg-epp-06.txt
draft-ietf-provreg-epp-contact-04.txt

According to the contacts specification, page 17:

  ...  
  A <contact:id> element that contains the desired server-unique
  identifier for the contact to be created.
  ...

<contact:id> values are server(registry)-unique but
client(registrar)-created. It would seem reasonable to partition the
possible values of <contact:id> among the various contacts so as to reduce
the possibility of name collisions on creation of new contacts. This would
be a matter of server policy. One possible scheme would be to allocate a 4
character prefix to each registrar, and allow the registrar to allocate
their own 12-character suffix. Doing so would allow each registrar to manage
a subset of the complete namespace without too much overhead.

If we adopt this scheme, or a similar one, there's nothing in EPP itself to
prevent one client using identifiers from another client's subset of the
contact:id values. Would it be reasonable for a server to maintain allowed
prefixes each client, and validate incoming <contact:create> commands to
ensure that <contact:id> fields match allowed values? Again this would be a
matter of service policy?

Any thoughts on the above would be appreciated.

Rob Burbidge


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3J9cxTB005188 for <[e-mail]>; Fri, 19 Apr 2002 11:38:59 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3J9cxVV005187 for ietf-provreg-outgoing; Fri, 19 Apr 2002 11:38:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3J9cwTB005182 for <[e-mail]>; Fri, 19 Apr 2002 11:38:58 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <20RK2J16>; Fri, 19 Apr 2002 10:38:55 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: <postalInfo> element in contact management
Date: Fri, 19 Apr 2002 10:38:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Source :draft-ietf-provreg-epp-contact-04.txt

Quote from the <contact:info> command page 11
  ... 
  One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms.  If an
  internationalized form is provided, it MUST be listed first and
  element content MUST be represented in a subset of UTF-8 that can be
  represented in the 7-bit US-ASCII character set.  If a localized form
  is provided, element content MAY be represented in unrestricted UTF-8.
  ...

If two <contact:postalInfo> elements are provided the above paragraph makes
it clear which one is the internationalized form and which is the localized
form. However, if only one <contact:postalInfo> element is supplied, is it
understood to be internationalized or localized?

A similar comment applies to <contact:create>. Our registry database has the
ability to store two postalInfo entries, and distinguishes between
internationalized and localized addresses. If <contact:create> supplies only
one <contact:postalInfo>, where do we put the data?

Thanks for any help you can give; prompt replies to earlier questions (even
idiot ones) has been much appreciated.

Rob Burbidge



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3IG6KTB000393 for <[e-mail]>; Thu, 18 Apr 2002 18:06:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3IG6Kjf000392 for ietf-provreg-outgoing; Thu, 18 Apr 2002 18:06:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3IG6JTB000387 for <[e-mail]>; Thu, 18 Apr 2002 18:06:19 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA00545 for <[e-mail]>; Thu, 18 Apr 2002 11:46:05 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQYW18>; Thu, 18 Apr 2002 12:06:18 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "Newton, Andrew" <[e-mail]>
Cc: [e-mail]
Subject: RE: XML Digital Signatures for EPP.
Date: Thu, 18 Apr 2002 12:06:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Andy,

I don't think canonicalization (c14n) is really an issue since it's a just a
process that describes how to produce a consistent representation of a
well-formed instance.  Looking at the spec [1] right now I don't see any
real issues.

On the other hand, you're probably right about trying to provide integrity,
authentication, and non-repudiation services at some other layer.  The XML
DSIG specs allow multiple transforms (such as c14n and perhaps compression)
to be applied prior to signing, but XML signatures add a lot of "wrapper"
that add to bandwidth and processing horsepower requirements.

Just for yuks I worked up an example [2] of a host <create> command
contained with an XML signature wrapper.  Don't try to validate this
signature since all I did was steal data to make the XML parser happy, but
it's illustrative of the overhead required.

-Scott-

[1]
http://www.w3.org/TR/xml-c14n

[2]
(long lines are going to get wrapped; sorry)

<?xml version='1.0'?>
<Signature Id="EPPSig" xmlns="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
   xmldsig-core-schema.xsd">
   
  <SignedInfo>
    <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710">
    </CanonicalizationMethod>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa">
    </SignatureMethod>
    <Reference URI="http://www.w3.org/TR/REC-xml-names/">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">
      </DigestMethod>
      <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
    </Reference>
  </SignedInfo>
  
 
<SignatureValue>MC0CFFrVLtRlkMc3Daon4BqqnkhCOlEaAhUAk8pH1iRNK+q1I+sisDTz2TFE
ALE=</SignatureValue>
  
  <KeyInfo>
    <KeyValue>
      <DSAKeyValue>
 
<P>2iY3w062sDB3/DIlLWOeG9+4UpmDZ0dyqRk9dLlNQ6qaXI7tOrjdIhm6n/eOw45AQtuYSp6sp
Ct9cQcNBAj22KvygvfJIIXX9sSQrugfGqifeSvY3VX5Sd1j+z0MSZ/n5jNt88uh2C11SAqX6nrXT
Y/1RwkoWRN23SYhOlaG0hU=</P>
        <Q>9B5ypLY9pMOmtxCeTDHgwdNFeGs=</Q>
 
<G>MuGAlqeB1ax+vyO2+Osubjhl7pHxLu47RIH+/M52DjESA9KMSrwzsYx8yNR2WooByrE0t6fu0
VncK7UK8olO4t7wpv2z4AFQPRVCKFwo0qgn5aKIkICGMlrRy81avb27wGcWothx3iPPMtFXtoDqK
0JItaI9R8zc1msFhM1GKMY=</G>
 
<Y>ctA8YGxrtngg/zKVvqEOefnwmViFztcnPBYPlJsvh6yKI4iDm68fnp4Mi3RrJ6bZAygFrUIQL
xLjV+OJtgJAEto0xAs+Mehuq1DkSFEpP3oDzCTOsrOiS1DwQe4oIb7zVk/9l7aPtJMHW0LVlMdwZ
NFNNJoqMcT2ZfCPrfvYvQ0=</Y>
      </DSAKeyValue>
    </KeyValue>
  </KeyInfo>
  
  <Object>
    <SignatureProperties>
      <SignatureProperty Target="#EPPSig">
        <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
         epp-1.0.xsd">
          <command>
            <create>
              <host:create
               xmlns:host="urn:ietf:params:xml:ns:host-1.0"
               xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
               host-1.0.xsd">
                <host:name>ns1.example.tld</host:name>
                <host:addr ip="v4">192.1.2.3</host:addr>
                <host:addr ip="v4">198.1.2.3</host:addr>
                <host:addr
                 ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
              </host:create>
            </create>
            <clTRID>ABC-12345</clTRID>
          </command>
        </epp>
      </SignatureProperty>
    </SignatureProperties>
  </Object>
</Signature>

> -----Original Message-----
> From: Andrew Newton [mailto:[e-mail]]
> Sent: Thursday, April 18, 2002 11:37 AM
> To: Hollenbeck, Scott
> Cc: 'Roger Castillo Cortazar'; [e-mail]
> Subject: RE: XML Digital Signatures for EPP.
> 
> 
> It has been a bit since I looked at this stuff, so forgive if 
> I get any
> of it wrong.  But it is my understanding that XML D-Sig uses XML
> Canonicalization which is DTD based.  This may pose a problem with EPP
> since its schema language is XML Schema.
> 
> I think doing this at the application transport level is a 
> better idea. 
> You also get the advantage of being able to run compression 
> against the
> XML instance before encryption.
> 
> -andy
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3HLNnTB024941 for <[e-mail]>; Wed, 17 Apr 2002 23:23:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3HLNnHQ024940 for ietf-provreg-outgoing; Wed, 17 Apr 2002 23:23:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3HLNlTB024935 for <[e-mail]>; Wed, 17 Apr 2002 23:23:48 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA05003; Wed, 17 Apr 2002 17:03:28 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQYDDV>; Wed, 17 Apr 2002 17:23:41 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Roger Castillo Cortazar'" <[e-mail]>, [e-mail]
Subject: RE: XML Digital Signatures for EPP.
Date: Wed, 17 Apr 2002 17:23:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 2:31 PM
> To: [e-mail]
> Subject: XML Digital Signatures for EPP.
> 
> 
> Hi everybody.
> 
> We are working on an implementation of EPP for NIC-MX.
> 
> In our requirements we included a digital signature for all the
> object transform commands.
> 
> This will provide the means to authenticate the sender,
> verify the integrity of the information and to assure
> the non-repudiation of the command.
> 
> There is a lot of work from IETF and W3C on XML Signatures,
> we have some RFC's on signing models, canonical forms, etc.
> There are also a few SDK's for XML digital signatures.
> 
> This seems to be quite interesting and useful, any comments ?
> Is anyone working on something like this ?
> 
> Maybe this could be an interesting extension for EPP.
> What do you think ?

Roger,

I've been thinking about this from the very beginning, but haven't really
wanted to get started until the EPP core documents were finished and the XML
DSIG stuff firmed up a bit.  Now that we're getting close to finishing the
core documents and RFC 3275 has been published I plan on looking at it much
more closely.

One other thought: digital signatures can also be applied via Open PGP or
S/MIME, and this might play into the whole email transport thing that we've
talked about but not yet crafted an I-D for.  Maybe there's two or three
documents to be written around email, including a core spec and one each
describing PGP and S/MIME security wrappers.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3HIUDTB023981 for <[e-mail]>; Wed, 17 Apr 2002 20:30:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3HIUC4W023980 for ietf-provreg-outgoing; Wed, 17 Apr 2002 20:30:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.nic.mx (mail.nic.mx [200.23.1.17]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3HIUATB023975 for <[e-mail]>; Wed, 17 Apr 2002 20:30:11 +0200 (MEST)
Received: from rcastillo.nic.mx (rcastillo.nic.com.mx [200.33.1.31]) (authenticated (0 bits)) by mail.nic.mx (8.11.6/8.11.6) with ESMTP id g3HIUJC03005 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Wed, 17 Apr 2002 13:30:20 -0500 (CDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 13:30:44 -0500
To: [e-mail]
From: Roger Castillo Cortazar <[e-mail]>
Subject: XML Digital Signatures for EPP.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

Hi everybody.

We are working on an implementation of EPP for NIC-MX.

In our requirements we included a digital signature for all the
object transform commands.

This will provide the means to authenticate the sender,
verify the integrity of the information and to assure
the non-repudiation of the command.

There is a lot of work from IETF and W3C on XML Signatures,
we have some RFC's on signing models, canonical forms, etc.
There are also a few SDK's for XML digital signatures.

This seems to be quite interesting and useful, any comments ?
Is anyone working on something like this ?

Maybe this could be an interesting extension for EPP.
What do you think ?


Greetings.


Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGg2TB009868 for <[e-mail]>; Mon, 15 Apr 2002 18:42:02 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FGg2rf009867 for ietf-provreg-outgoing; Mon, 15 Apr 2002 18:42:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGg0TB009862 for <[e-mail]>; Mon, 15 Apr 2002 18:42:01 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA16448; Mon, 15 Apr 2002 12:21:43 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQWBYZ>; Mon, 15 Apr 2002 12:41:58 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: <domain:info> command and <host>
Date: Mon, 15 Apr 2002 12:41:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Monday, April 15, 2002 11:49 AM
> To: Ietf-Provreg (E-mail)
> Subject: <domain:info> command and <host>
> 
> 
> Can someone clarify the <host> return tag on the <domain:info> command? In
> "draft-ietf-provreg-epp-domain-04.txt" page 11, it is stated that <host>
> records contain "the fully qualified names of subordinate host objects
that
> exist under this superordinate domain object".  I can't see the point of
> this or how it can be achieved.
> 
> Given the following hypothetical scenario:
> 
> * The registry is for the ".tld" top level domain
> * A client has successfully created the domain "wibble.tld" along with
valid
> nameservers etc.
> * The client performs a <domain:info> query on "wibble.tld".
> 
> How can the registry return any information at all that relates to
> subordinate objects of "wibble.tld"? Presumably it has delegated
management
> of that domain to the domain's owner via the registrar, and presumably the
> owners DNS system is the only place that holds the definitive subordinate
> object listing. Or have I missed  something?

You've missed something.  The host draft states (section 1.1) that host
objects have a subordinate relationship to a domain object.  So, the
registry knows about all hosts in the repository created as children of
"wibble.tld", such as "ns1.wibble.tld".  The <info> command gives the client
the option to retrieve only subordinate hosts like ns1.wibble.tld, only
delegated hosts (the name servers to which wibble.tld has been delegated),
both delegated and subordinate hosts, or neither.  There is no requirement
for a client to register _all_ of the hosts that might exist in the
wibble.tld zone.

So, if you're asking if folks MUST create hosts objects for all wibble.tld
hosts, the answer is no.  Some server operator may come up with creative
things to do with host objects other than using them as name servers, and if
they get registered they'll be visible via the domain's <info> command.
However, the domain <info> command will not generally know anything about
hosts that exist only in the wibble.tld zone.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGanTB009839 for <[e-mail]>; Mon, 15 Apr 2002 18:36:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FGane8009838 for ietf-provreg-outgoing; Mon, 15 Apr 2002 18:36:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGalTB009833 for <[e-mail]>; Mon, 15 Apr 2002 18:36:47 +0200 (MEST)
Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA14238; Mon, 15 Apr 2002 09:36:40 -0700
Message-Id: <5.1.0.14.2.20020415092741.03391e70@127.0.0.1>
X-Sender: dcrocker@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 09:30:52 -0700
To: Rick Wesson <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: Decision on containers - status?
Cc: "Ietf-Provreg (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <5.1.0.14.2.20020415075505.01c2f600@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 09:15 AM 4/15/2002 -0700, Rick Wesson wrote:
>I'd actually disagree as mainiaing the efficiencies of contains is not
>very a complex task from a registrar point of view -- and since I've
>implemented more registrar back ends than anyone else I'm speaking from
>experence.

Rick,

Personally I think the layer of abstractions that containers offers is 
quite excellent and that the added complexity is not that great.  So I was 
quite surprised at the resistance to it.  However I'd say that the working 
group rough consensus about NOT wanting in required (or, at least, not 
wanting it at the present time) was undeniable.

So I thought that the compromise of making it an option was exactly the 
right choice.

If we are not going to specify the details now, that leaves the requirement 
that we keep the future use in mind and try to make sure we do not 
unintentionally prevent the addition later.

d/


----------
Dave Crocker  <mailto:[e-mail]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel [phone];  fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGFvTB009678 for <[e-mail]>; Mon, 15 Apr 2002 18:15:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FGFuN2009677 for ietf-provreg-outgoing; Mon, 15 Apr 2002 18:15:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FGFtTB009672 for <[e-mail]>; Mon, 15 Apr 2002 18:15:56 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g3FGFqfZ018557; Mon, 15 Apr 2002 09:15:52 -0700 (PDT)
Date: Mon, 15 Apr 2002 09:15:52 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Edward Lewis <[e-mail]>, Robert Burbidge <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Re: Decision on containers - status?
In-Reply-To: <5.1.0.14.2.20020415075505.01c2f600@127.0.0.1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Dave,

I'd actually disagree as mainiaing the efficiencies of contains is not
very a complex task from a registrar point of view -- and since I've
implemented more registrar back ends than anyone else I'm speaking from
experence.

-rick


On Mon, 15 Apr 2002, Dave Crocker wrote:

> At 10:34 AM 4/15/2002 -0400, Edward Lewis wrote:
> >(dormantly) around.  The third possibility is there in case there are some
> >folks that feel it is good, "but not right now."
> >
> >As far as the PS - it might be that containers are left as an
> >implementation-specific option.
>
> Containers offers the benefit of freedom.  It decouples the details of
> interacting with the registrar's customer from the details of interacting
> with the registry on behalf of that customer.
>
> Without containers, the two are tied together.  For many registrar
> environments, this is not a problem.  For others -- particularly
> larger-scale ones -- the limitation requires many more registrary/registry
> interactions and more complicated bookkeeping.
>
> And bookkeeping is the word.  I don't know enough about bookkeeping to know
> the standard term, but I know that this sort of decoupling is quite common
> for accounting systems that have any sort of scale.
>
> So, folks, yes it is less work now.  And clearly many registrars will not
> reach the size that needs containers.  Others will grow into the
> need.  Will, not might.
>
> That says that containers needs to be an option.  Specification of options
> often can be deferred.  And given the knowledge about them, now, the
> requirement is to make sure that the current specification does not make
> adding containers difficult.
>
> d/
>
>
> ----------
> Dave Crocker  <mailto:[e-mail]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel [phone];  fax [phone]
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FFmqTB009571 for <[e-mail]>; Mon, 15 Apr 2002 17:48:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FFmqBK009570 for ietf-provreg-outgoing; Mon, 15 Apr 2002 17:48:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FFmoTB009565 for <[e-mail]>; Mon, 15 Apr 2002 17:48:51 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <20RKH0SV>; Mon, 15 Apr 2002 16:48:49 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: <domain:info> command and <host>
Date: Mon, 15 Apr 2002 16:48:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Can someone clarify the <host> return tag on the <domain:info> command? In
"draft-ietf-provreg-epp-domain-04.txt" page 11, it is stated that <host>
records contain "the fully qualified names of subordinate host objects that
exist under this superordinate domain object".  I can't see the point of
this or how it can be achieved.

Given the following hypothetical scenario:

* The registry is for the ".tld" top level domain
* A client has successfully created the domain "wibble.tld" along with valid
nameservers etc.
* The client performs a <domain:info> query on "wibble.tld".

How can the registry return any information at all that relates to
subordinate objects of "wibble.tld"? Presumably it has delegated management
of that domain to the domain's owner via the registrar, and presumably the
owners DNS system is the only place that holds the definitive subordinate
object listing. Or have I missed  something?

In contrast, I see no problems with returning <ns> objects, as it is clear
that the registry may well have name server information that relates to the
domain. In fact, given the way that <domain:create> works, it's very likely.

Thanks
Rob Burbidge



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FF4CTB009346 for <[e-mail]>; Mon, 15 Apr 2002 17:04:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FF4Buc009345 for ietf-provreg-outgoing; Mon, 15 Apr 2002 17:04:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FF49TB009339 for <[e-mail]>; Mon, 15 Apr 2002 17:04:10 +0200 (MEST)
Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA10212; Mon, 15 Apr 2002 08:04:04 -0700
Message-Id: <5.1.0.14.2.20020415075505.01c2f600@127.0.0.1>
X-Sender: dcrocker@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 08:00:55 -0700
To: Edward Lewis <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: Decision on containers - status?
Cc: Robert Burbidge <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
In-Reply-To: <v0313030ab8e0931be647@[199.171.39.21]>
References: < <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 10:34 AM 4/15/2002 -0400, Edward Lewis wrote:
>(dormantly) around.  The third possibility is there in case there are some
>folks that feel it is good, "but not right now."
>
>As far as the PS - it might be that containers are left as an
>implementation-specific option.

Containers offers the benefit of freedom.  It decouples the details of 
interacting with the registrar's customer from the details of interacting 
with the registry on behalf of that customer.

Without containers, the two are tied together.  For many registrar 
environments, this is not a problem.  For others -- particularly 
larger-scale ones -- the limitation requires many more registrary/registry 
interactions and more complicated bookkeeping.

And bookkeeping is the word.  I don't know enough about bookkeeping to know 
the standard term, but I know that this sort of decoupling is quite common 
for accounting systems that have any sort of scale.

So, folks, yes it is less work now.  And clearly many registrars will not 
reach the size that needs containers.  Others will grow into the 
need.  Will, not might.

That says that containers needs to be an option.  Specification of options 
often can be deferred.  And given the knowledge about them, now, the 
requirement is to make sure that the current specification does not make 
adding containers difficult.

d/


----------
Dave Crocker  <mailto:[e-mail]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel [phone];  fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FEfQTB009217 for <[e-mail]>; Mon, 15 Apr 2002 16:41:26 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FEfQMl009216 for ietf-provreg-outgoing; Mon, 15 Apr 2002 16:41:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FEfPTB009211 for <[e-mail]>; Mon, 15 Apr 2002 16:41:25 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g3FEfKfZ008402; Mon, 15 Apr 2002 07:41:20 -0700 (PDT)
Date: Mon, 15 Apr 2002 07:41:20 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Robert Burbidge <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Re: Decision on containers - status?
In-Reply-To: <v0313030ab8e0931be647@[199.171.39.21]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

my vote is to drop it, if there isn't interst amend the charter.

-rick

On Mon, 15 Apr 2002, Edward Lewis wrote:

> At the end of the month, Jaap and I will be able to talk at the RIPE
> meeting, so we (the chairs) will have something to say then.  There are
> three possible outcomes - dropping it, pushing on it, or letting it lie
> (dormantly) around.  The third possibility is there in case there are some
> folks that feel it is good, "but not right now."
>
> As far as the PS - it might be that containers are left as an
> implementation-specific option.
>
> At 9:05 AM -0400 4/15/02, Robert Burbidge wrote:
> >According to "Goals and Milestones" on
> >http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
> >deadline for deciding whether to support containers. Has this decision been
> >made yet and if so what is it? If not, is there a more specific deadline for
> >the decision?
> >
> >Rob Burbidge, Poptel
> >
> >(PS: Hope we're dropping them, less work to implement :-))
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: [phone]                      Email: [e-mail]
>
> Last day is Wednesday, April 24, 2002...
>
> Opinions expressed are property of my evil twin, not my employer.
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FEYZTB009161 for <[e-mail]>; Mon, 15 Apr 2002 16:34:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FEYZr3009160 for ietf-provreg-outgoing; Mon, 15 Apr 2002 16:34:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FEYXTB009155 for <[e-mail]>; Mon, 15 Apr 2002 16:34:33 +0200 (MEST)
Received: by sentry.gw.tislabs.com; id KAA27326; Mon, 15 Apr 2002 10:40:21 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027304; Mon, 15 Apr 02 10:39:55 -0400
Received: from [10.33.10.175] (dyn175.gw.tislabs.com [10.33.10.175]) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id g3FEY5G02520; Mon, 15 Apr 2002 10:34:05 -0400 (EDT)
X-Sender: [e-mail]
Message-Id: <v0313030ab8e0931be647@[199.171.39.21]>
In-Reply-To:  <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 15 Apr 2002 10:34:59 -0400
To: Robert Burbidge <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: Decision on containers - status?
Cc: "Ietf-Provreg (E-mail)" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At the end of the month, Jaap and I will be able to talk at the RIPE
meeting, so we (the chairs) will have something to say then.  There are
three possible outcomes - dropping it, pushing on it, or letting it lie
(dormantly) around.  The third possibility is there in case there are some
folks that feel it is good, "but not right now."

As far as the PS - it might be that containers are left as an
implementation-specific option.

At 9:05 AM -0400 4/15/02, Robert Burbidge wrote:
>According to "Goals and Milestones" on
>http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
>deadline for deciding whether to support containers. Has this decision been
>made yet and if so what is it? If not, is there a more specific deadline for
>the decision?
>
>Rob Burbidge, Poptel
>
>(PS: Hope we're dropping them, less work to implement :-))


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: [phone]                      Email: [e-mail]

Last day is Wednesday, April 24, 2002...

Opinions expressed are property of my evil twin, not my employer.




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FD5eTB008694 for <[e-mail]>; Mon, 15 Apr 2002 15:05:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g3FD5esH008693 for ietf-provreg-outgoing; Mon, 15 Apr 2002 15:05:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g3FD5cTB008688 for <[e-mail]>; Mon, 15 Apr 2002 15:05:39 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <20GB7F25>; Mon, 15 Apr 2002 14:05:37 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Decision on containers - status?
Date: Mon, 15 Apr 2002 14:05:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

According to "Goals and Milestones" on
http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
deadline for deciding whether to support containers. Has this decision been
made yet and if so what is it? If not, is there a more specific deadline for
the decision?

Rob Burbidge, Poptel

(PS: Hope we're dropping them, less work to implement :-))



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38CGpd1025333 for <[e-mail]>; Mon, 8 Apr 2002 14:16:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g38CGp52025332 for ietf-provreg-outgoing; Mon, 8 Apr 2002 14:16:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38CGod1025327 for <[e-mail]>; Mon, 8 Apr 2002 14:16:50 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA26410; Mon, 8 Apr 2002 07:56:31 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <G5S3RQLW>; Mon, 8 Apr 2002 08:16:47 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: Session and session-less commands in EPP
Date: Mon, 8 Apr 2002 08:16:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Monday, April 08, 2002 5:44 AM
> To: Ietf-Provreg (E-mail)
> Subject: Session and session-less commands in EPP
> 
> 
> draft-ietf-provreg-epp-06.txt, Section 2.8.1
> 
> Session and session-less operation
> ==================================
> 
> "Session-oriented and session-less operating modes MUST NOT be mixed".
> Intuitively I think you mean that the two modes cannot be 
> mixed within the
> same "session" (to use the term "session" in its most generic sense).
> However, consider the following outline sequence of EPP commands and
> responses
> 
> 1 C: <hello>....
>   S: <greeting>...
> 2 C: <command><creds>...</creds><check>...</check></command>
>   S: <response>...</response>
> 3 C: <command><creds>...</creds><login>...</login></command>
>   S: <response>...</response>
> 4 C: <command><check>...</check></command>
>   S: <response>...</response>
> 5 C: <command><logout></logout></command>
>   S: <response>...</response>
> 
> In this sequence, the <check> command [2] contains its own 
> credentials and
> it has not logged in, which seems fair. The <login> command [3] then
> provides credentials, and these are used by the second check 
> command [4]. As
> far as I can see, this is completely in accordance with the 
> specification.
> But as you can see it mixes "sessioned" and "session-free" 
> operations. We
> might stipulate that a <login> command MUST be the first command after
> <hello> if a client wants to use session operations. But I don't think
> that's particularly desirable.

I agree with your last sentence, and that's why the text currently reads the
way it does.  I don't see a problem with creds-containing commands preceding
a <login> if the server supports such behavior.  Perhaps changing the
"Session-oriented and session-less operating modes MUST NOT be mixed"
sentence to something like "Session-less operating mode MUST NOT be used
within the bounds of an established <login> ... <logout> session" would make
this more clear.

> <logout> command
> ================
> 
> "Commands other than the login command MUST NOT include 
> identity credentials
> when submitted after successfully processing a <login> 
> command". This is
> reasonable. However, what happens AFTER a <logout> command? 
> The presumably
> releases the credential set at the server end. Would it be 
> possible to send
> a <command> that includes <creds> after a successful <logout>? If the
> command sequence outlined above is valid, then a sense of 
> symmetry would
> suggest that the answer is "yes", but this would be in 
> conflict with the
> quoted statement above. 
> 
> According to draft-ietf-provreg-epp-tcp-04.txt, "an EPP 
> session is nominally
> ended by the client issuing an EPP <logout> command. A server 
> receiving an
> EPP <logout> command  MUST end the EPP session and close the TCP
> session...". This would seem to preclude <command> elements 
> with <creds>
> after a <logout> command. A similar comment is found in the 
> BEEP protocol
> mapping.

What happens after a <logout> is processed depends on the transport.  That's
why the base specs doesn't say anything specific, and the TCP and BEEP
documents specifically do address the topic.  It might be possible to add a
sentence to the base spec that says "what happens after logout is
transport-dependent", but I wouldn't want to say much more than that because
of the number of transport-related variables.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38BwAd1025202 for <[e-mail]>; Mon, 8 Apr 2002 13:58:10 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g38BwAWO025201 for ietf-provreg-outgoing; Mon, 8 Apr 2002 13:58:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38Bw9d1025196 for <[e-mail]>; Mon, 8 Apr 2002 13:58:09 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA25932; Mon, 8 Apr 2002 07:37:50 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <G5S3RQHQ>; Mon, 8 Apr 2002 07:58:06 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: EPP/TCP session layer
Date: Mon, 8 Apr 2002 07:58:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Monday, April 08, 2002 5:44 AM
> To: Ietf-Provreg (E-mail)
> Subject: EPP/TCP session layer
> 
> 
> Meaning of the word "nominally"
> ===============================
> 
> draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3
> 
> "An EPP session is nominally ended by ..."
> 
> What does "nominally" mean in this context? If it means 
> "existing in name
> only" then does this mean the session is not really ended? 
> This needs to be
> clarified.

Hmm, I used the word here and in other parts of the specs assuming that
nominal was a synonym for words like standard, typical, common, and usual.
Looking at my dictionary and thesaurus now I see that's not the case.  As
this is an editorial fix I assume I can deal with it after we receive last
call feedback from the IESG.

> Datagrams
> =========
> 
> draft-ietf-provreg-epp-tcp-04.txt, section 4
> 
> Is it a requirement that a datagram contains exactly one EPP 
> XML instance?
> It seems reasonable to suppose that a datagram cannot contain 
> fragments of
> an XML document, but can it contain more than one complete 
> well-formed EPP
> XML instance? I suppose not, but can we clarify this.

The last paragraph of section 3 already addresses this.

Meta-comment: the documents have already been through WG and IETF last call,
so I don't have a lot of freedom to change anything until after we hear from
the IESG.  This feedback is good, but please don't expect new versions of
the documents until some time after IESG commentary is provided - and even
then I have to be careful about what gets changed.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38Boad1025156 for <[e-mail]>; Mon, 8 Apr 2002 13:50:36 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g38Boa7t025155 for ietf-provreg-outgoing; Mon, 8 Apr 2002 13:50:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38BoYd1025150 for <[e-mail]>; Mon, 8 Apr 2002 13:50:35 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g38BiLX58775; Mon, 8 Apr 2002 07:44:21 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Robert Burbidge <[e-mail]>
cc: "Ietf-Provreg (E-mail)" <[e-mail]>, [e-mail]
Subject: Re: Session and session-less commands in EPP 
In-Reply-To: Your message of "Mon, 08 Apr 2002 10:44:07 BST." <[e-mail]> 
Date: Mon, 08 Apr 2002 07:44:21 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Morning Robert,

The session-less model we'd (or we've) in mind is epp/smtp.

draft-ietf-provreg-epp-06.txt is (nomially, pardon the abuse of language)
transport-independent, so it must contain guidance (manditory to implement)
on generic session-full and generic session-less transports.

Assume generic session-full transport
1 C: <hello>....
  S: <greeting>...
2 C: <command><creds>...</creds><check>...</check></command>
  ...

Assume generic session-less transport
1 C: <hello>....
2 C: <command><creds>...</creds><check>...</check></command>
...

The difference is in the <greeting> reply, which is manditory for the server
to return when prompted if the service is over a connection, and manditory to
prompt for (but not necessarily get) if the service is connection-less.

Since the client may request a <greeting> at any time by sending a <hello>,
making a requirement as to the next command, e.g., <login> if session is
desired, seems problematic.

1 C: <hello>
  S: <greeting>
2 C: <hello>
  S: <greeting>
3 C: <command><creds>...</creds><login>...</login></command>

Assuming one were implementing an error test case, then you've suggested
that at 3 an error is returned.

I thought the text in section 2.4, Command Format, at lines 539-544 were
clear, <login> and <logout> define server session, repeated in section
2.8.1, Session Management Commands, at lines 1055-1062, was clear.

> But as you can see it mixes "sessioned" and "session-free" operations.

I guess I don't see this. Maybe another cup of coffee would help.

> after a <logout> command. A similar comment is found in the BEEP protocol
> mapping.
>
> Does anyone have any thoughts on this?

The first thought that went through my mind was "Oh joy! A careful reader
of the BEEP draft!"

I think that what you are doing is (understandibly) missing the bits written
in invisible, or archived mailing list ink, that said anything over tcp is
session-full, epp/tcp or epp/beep/tcp, and that epp/smtp is session-less.

I'm really pleased to see implementor-esque comments from someone at Poptel,
my regards to Stu and Cazz.

Cheers,
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38B2kd1024954 for <[e-mail]>; Mon, 8 Apr 2002 13:02:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g38B2k89024953 for ietf-provreg-outgoing; Mon, 8 Apr 2002 13:02:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38B2jd1024948 for <[e-mail]>; Mon, 8 Apr 2002 13:02:45 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g38AuUX58676; Mon, 8 Apr 2002 06:56:30 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Robert Burbidge <[e-mail]>
cc: "Ietf-Provreg (E-mail)" <[e-mail]>, [e-mail]
Subject: Re: EPP/TCP session layer
In-Reply-To: Your message of "Mon, 08 Apr 2002 10:43:49 BST." <[e-mail]> 
Date: Mon, 08 Apr 2002 06:56:30 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Moring Robert,

The usage in draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3, of
"monimally" is not "existing in name only". Please see the following:

draft-ietf-provreg-epp-06.txt, section 3, Result Codes (at line 2647)
  1000    "Command completed successfully"
  This is the nominal response code for a successfully completed
  command.

draft-ietf-provreg-epp-beep-01.txt, section 2, Session Management (at 147)
   An EPP session is nominally ended by the client issuing an EPP
   <logout> command which terminates the respective BEEP channel.  A  
   server receiving an EPP <logout> command MUST end the EPP session and
   release the BEEP channel.


draft-ietf-provreg-epp-contact-04.txt, section 2.2, Status Values (at 242)
  ok
      
  This is the nominal status value for an object that has no pending
  operations or prohibitions.

The same usages are also in:
draft-ietf-provreg-epp-container-01.txt, section 2.5, Status Values (at 638)
draft-ietf-provreg-epp-domain-04.txt, section 2.3, Status Values (at 260)
draft-ietf-provreg-epp-host-04.txt, section 2.3, Status Values (at 242)


See also:
draft-ietf-provreg-grrp-reqs-06.txt, at 744,

3.5 Domain Status Indicators

  [1] The protocol MUST provide status indicators that identify the
  operational state of a domain name.  Indicators MAY be provided to
  identify a newly created state (the domain has been registered but has
  not yet appeared in a zone), a nominal active state (the domain can be
  modified and is published in a zone), an inactive state (the domain
  can be modified but is not published in a zone because it has no
  authoritative name servers), a hold state (the domain can not be
  modified and is not published in a zone), a lock state (the domain can
  not be modified and is published in a zone), a pending transfer state,
  and a pending removal state.

and at 963, 

7.4 Maintainability
  
  [1] Maintainability is a measure of the extent to which a protocol can
  be adapted or modified to address unforeseen operational needs or
  defects.  The protocol SHOULD be developed under the nominal working  
  group processes of the IETF to provide a well-known mechanism for  
  ongoing maintenance.

I confess I hadn't given the datagram section any thought at all. From an
implementor point of view isn't this equivalent to doing one write to the
wire per command or response?

I'm interested in understanding the scenario where two wf epp xml instances
(not equivalent, due to idempotency) exist in one socket buffer, for the use
case of transport over tcp. 

Cheers,
Eric






Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g389iGd1024567 for <[e-mail]>; Mon, 8 Apr 2002 11:44:16 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g389iG1q024566 for ietf-provreg-outgoing; Mon, 8 Apr 2002 11:44:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g389iEd1024561 for <[e-mail]>; Mon, 8 Apr 2002 11:44:15 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <G05997VF>; Mon, 8 Apr 2002 10:44:13 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: Session and session-less commands in EPP
Date: Mon, 8 Apr 2002 10:44:07 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

draft-ietf-provreg-epp-06.txt, Section 2.8.1

Session and session-less operation
==================================

"Session-oriented and session-less operating modes MUST NOT be mixed".
Intuitively I think you mean that the two modes cannot be mixed within the
same "session" (to use the term "session" in its most generic sense).
However, consider the following outline sequence of EPP commands and
responses

1 C: <hello>....
  S: <greeting>...
2 C: <command><creds>...</creds><check>...</check></command>
  S: <response>...</response>
3 C: <command><creds>...</creds><login>...</login></command>
  S: <response>...</response>
4 C: <command><check>...</check></command>
  S: <response>...</response>
5 C: <command><logout></logout></command>
  S: <response>...</response>

In this sequence, the <check> command [2] contains its own credentials and
it has not logged in, which seems fair. The <login> command [3] then
provides credentials, and these are used by the second check command [4]. As
far as I can see, this is completely in accordance with the specification.
But as you can see it mixes "sessioned" and "session-free" operations. We
might stipulate that a <login> command MUST be the first command after
<hello> if a client wants to use session operations. But I don't think
that's particularly desirable.

<logout> command
================

"Commands other than the login command MUST NOT include identity credentials
when submitted after successfully processing a <login> command". This is
reasonable. However, what happens AFTER a <logout> command? The presumably
releases the credential set at the server end. Would it be possible to send
a <command> that includes <creds> after a successful <logout>? If the
command sequence outlined above is valid, then a sense of symmetry would
suggest that the answer is "yes", but this would be in conflict with the
quoted statement above. 

According to draft-ietf-provreg-epp-tcp-04.txt, "an EPP session is nominally
ended by the client issuing an EPP <logout> command. A server receiving an
EPP <logout> command  MUST end the EPP session and close the TCP
session...". This would seem to preclude <command> elements with <creds>
after a <logout> command. A similar comment is found in the BEEP protocol
mapping.

Does anyone have any thoughts on this?



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g389hxd1024559 for <[e-mail]>; Mon, 8 Apr 2002 11:43:59 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g389hw0s024558 for ietf-provreg-outgoing; Mon, 8 Apr 2002 11:43:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g389hvd1024553 for <[e-mail]>; Mon, 8 Apr 2002 11:43:57 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <G05997V1>; Mon, 8 Apr 2002 10:43:53 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: EPP/TCP session layer
Date: Mon, 8 Apr 2002 10:43:49 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Meaning of the word "nominally"
===============================

draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3

"An EPP session is nominally ended by ..."

What does "nominally" mean in this context? If it means "existing in name
only" then does this mean the session is not really ended? This needs to be
clarified.

Datagrams
=========

draft-ietf-provreg-epp-tcp-04.txt, section 4

Is it a requirement that a datagram contains exactly one EPP XML instance?
It seems reasonable to suppose that a datagram cannot contain fragments of
an XML document, but can it contain more than one complete well-formed EPP
XML instance? I suppose not, but can we clarify this.




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34F5Jd1001325 for <[e-mail]>; Thu, 4 Apr 2002 17:05:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g34F5JTM001324 for ietf-provreg-outgoing; Thu, 4 Apr 2002 17:05:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34F5Hd1001319 for <[e-mail]>; Thu, 4 Apr 2002 17:05:18 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <G0599SWK>; Thu, 4 Apr 2002 16:05:15 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result> or  <response>?
Date: Thu, 4 Apr 2002 16:05:09 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks Scott. You are right about the page numbers; that was a silly mistake
on my part. I can see that the schema is controlling, but anything you can
do to clarify the prose description would be helpful. 

Rob Burbidge

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: 04 April 2002 15:12
To: 'Robert Burbidge'; '[e-mail]'
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result>
or <response>?


Robert,

I think the text you're referring to is actually on page 12 (my copy of -06
has a sample <greeting> and the start of the command description section on
page 9), but FWIW the indentation does indeed need to be fixed.  The schema
is controlling, and it clearly states that the <value> and <data> elements
are child elements of the <result> element, not the <response> element.

During the document last call someone suggested numbering the element
description paragraphs so that child relationships would be more clear, and
not potentially screwed up by indentation problems.  Assuming that the IESG
is OK with that idea I'll be adding numbers into the next version of the
documents.  If not, the indentation will be fixed.

-Scott-

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 7:46 AM
> To: '[e-mail]'
> Subject: Ambiguity: <value> and <data> tags belong inside <result> or
> <res ponse>?
> 
> 
> Since this is my first posting to this list, I hope that (a) 
> it gets there
> and (b) it makes sense. Here goes...
> 
> Page 9 of draft-ietf-provreg-epp-06.txt, implies that the 
> <value> elements
> are contained within <response>. I say "implied" because the 
> only indication
> of containment at that point is the left paragraph indent. 
> However, the
> example on page 15 shows that value is contained inside 
> <result>. A quick
> cross-reference to the schema entry on page 60 shows that <value> is
> supposed to be in <result>, which implies that page 9 is in 
> error in this
> respect. 
> 
> I think the same comment applies for the <data> tag, judging 
> by the schema.
> 
> Would anyone like to comment on this?
> 
> Rob Burbidge
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34ECQd1001029 for <[e-mail]>; Thu, 4 Apr 2002 16:12:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g34ECQ79001028 for ietf-provreg-outgoing; Thu, 4 Apr 2002 16:12:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34ECOd1001023 for <[e-mail]>; Thu, 4 Apr 2002 16:12:25 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA27353; Thu, 4 Apr 2002 08:52:03 -0500 (EST)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <G5SBXVVH>; Thu, 4 Apr 2002 09:12:21 -0500
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result> or  <response>?
Date: Thu, 4 Apr 2002 09:12:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Robert,

I think the text you're referring to is actually on page 12 (my copy of -06
has a sample <greeting> and the start of the command description section on
page 9), but FWIW the indentation does indeed need to be fixed.  The schema
is controlling, and it clearly states that the <value> and <data> elements
are child elements of the <result> element, not the <response> element.

During the document last call someone suggested numbering the element
description paragraphs so that child relationships would be more clear, and
not potentially screwed up by indentation problems.  Assuming that the IESG
is OK with that idea I'll be adding numbers into the next version of the
documents.  If not, the indentation will be fixed.

-Scott-

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 7:46 AM
> To: '[e-mail]'
> Subject: Ambiguity: <value> and <data> tags belong inside <result> or
> <res ponse>?
> 
> 
> Since this is my first posting to this list, I hope that (a) 
> it gets there
> and (b) it makes sense. Here goes...
> 
> Page 9 of draft-ietf-provreg-epp-06.txt, implies that the 
> <value> elements
> are contained within <response>. I say "implied" because the 
> only indication
> of containment at that point is the left paragraph indent. 
> However, the
> example on page 15 shows that value is contained inside 
> <result>. A quick
> cross-reference to the schema entry on page 60 shows that <value> is
> supposed to be in <result>, which implies that page 9 is in 
> error in this
> respect. 
> 
> I think the same comment applies for the <data> tag, judging 
> by the schema.
> 
> Would anyone like to comment on this?
> 
> Rob Burbidge
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34Ck7d1000549 for <[e-mail]>; Thu, 4 Apr 2002 14:46:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g34Ck68a000548 for ietf-provreg-outgoing; Thu, 4 Apr 2002 14:46:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g34Ck5d1000543 for <[e-mail]>; Thu, 4 Apr 2002 14:46:06 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <G0599SJ0>; Thu, 4 Apr 2002 13:45:57 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Ambiguity: <value> and <data> tags belong inside <result> or <res ponse>?
Date: Thu, 4 Apr 2002 13:45:47 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Since this is my first posting to this list, I hope that (a) it gets there
and (b) it makes sense. Here goes...

Page 9 of draft-ietf-provreg-epp-06.txt, implies that the <value> elements
are contained within <response>. I say "implied" because the only indication
of containment at that point is the left paragraph indent. However, the
example on page 15 shows that value is contained inside <result>. A quick
cross-reference to the schema entry on page 60 shows that <value> is
supposed to be in <result>, which implies that page 9 is in error in this
respect. 

I think the same comment applies for the <data> tag, judging by the schema.

Would anyone like to comment on this?

Rob Burbidge



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g33Kald1024811 for <[e-mail]>; Wed, 3 Apr 2002 22:36:47 +0200 (MEST)
Received: by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g33Kalh2024810 for ietf-provreg-outgoing; Wed, 3 Apr 2002 22:36:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g33Kahd1024805 for <[e-mail]>; Wed, 3 Apr 2002 22:36:43 +0200 (MEST)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g33KafZ15865; Wed, 3 Apr 2002 14:36:41 -0600
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <HGJXXQNF>; Wed, 3 Apr 2002 14:36:36 -0600
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Documents for the WG
Date: Wed, 3 Apr 2002 14:36:27 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Ed,

We have a continuous interest in containers and beep transport. However,
they are not high on our priority right now. We hope that we would be able
to revisit them in the future.

We also think that the guideline document is very important. We would like
to participate in the effort when the time comes.

We will try to put out an I-D on "push" as an individual contribution to the
WG for the next IETF meeting in Yokohoma in July.

Cheers,

--Hong

-----Original Message-----
From: Edward Lewis [mailto:[e-mail]]
Sent: Tuesday, April 02, 2002 10:23 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Documents for the WG


This is mostly for the benefit of folks that were not at the provreg
meeting last month in Minneapolis.  If anyone feels to submit input on
these, go ahead, I'd prefer that we get comments into the archives.

There are four/five items to talk about under the subject of documents...

1) Containers - We've seen no discussion generated by the message I sent
nearly two weeks ago.  We'll soon be requesting that that document be
dropped from the WG list.

2) Transport via BEEP - During the meeting this document got a warm
reception, but not an overwhelming one.  Comments on this?  A few folks did
have an interest, but no one has stepped forward to volunteer to be an
editor/author.

3) Transport via SMTP - This also got a warm reception.  We are pursuing
volunteers to either edit or provide content for this.  One side comment:
there are a lot of ccTLD's that are currently relying on SMTP for
registration - of course without EPP.  Some of the TLDs plan to pick up EPP
when it is available, there is a question of whether the TLDs will also
switch from e-mail to TCP as a "transport".  If the switch is to TCP, then
perhaps transport over e-mail gets by-passed.

4) Guidelines for Extentions - This document arose from situations in which
proposed extensions to EPP might break EPP.  Over the next few months, as
implemenations begin and/or mature, there may be enough gathered wisdom to
document a reference on how to extend EPP.  The provreg group will not last
for the lifetime for EPP, and Scott may not be available to advise others
on how to extend EPP, so we should document some examples.  And I am not
implying that Scott should write this.  This document got some initial
support at the meeting, but it is probably too early to write this.

5) "Push" - There was to be a "push" document at one time.  It seems to
have been largely forgotten.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: [phone]                      Email: [e-mail]

Opinions expressed are property of my evil twin, not my employer.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g32FMJd1015799 for <[e-mail]>; Tue, 2 Apr 2002 17:22:19 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g32FMJw6015798 for ietf-provreg-outgoing; Tue, 2 Apr 2002 17:22:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g32FMId1015793 for <[e-mail]>; Tue, 2 Apr 2002 17:22:18 +0200 (MEST)
Received: by sentry.gw.tislabs.com; id KAA14910; Tue, 2 Apr 2002 10:27:59 -0500 (EST)
Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma014901; Tue, 2 Apr 02 10:27:57 -0500
X-Sender: [e-mail]
Message-Id: <v03130306b8cf7d4545de@[199.171.39.21]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Apr 2002 10:22:53 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Documents for the WG
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

This is mostly for the benefit of folks that were not at the provreg
meeting last month in Minneapolis.  If anyone feels to submit input on
these, go ahead, I'd prefer that we get comments into the archives.

There are four/five items to talk about under the subject of documents...

1) Containers - We've seen no discussion generated by the message I sent
nearly two weeks ago.  We'll soon be requesting that that document be
dropped from the WG list.

2) Transport via BEEP - During the meeting this document got a warm
reception, but not an overwhelming one.  Comments on this?  A few folks did
have an interest, but no one has stepped forward to volunteer to be an
editor/author.

3) Transport via SMTP - This also got a warm reception.  We are pursuing
volunteers to either edit or provide content for this.  One side comment:
there are a lot of ccTLD's that are currently relying on SMTP for
registration - of course without EPP.  Some of the TLDs plan to pick up EPP
when it is available, there is a question of whether the TLDs will also
switch from e-mail to TCP as a "transport".  If the switch is to TCP, then
perhaps transport over e-mail gets by-passed.

4) Guidelines for Extentions - This document arose from situations in which
proposed extensions to EPP might break EPP.  Over the next few months, as
implemenations begin and/or mature, there may be enough gathered wisdom to
document a reference on how to extend EPP.  The provreg group will not last
for the lifetime for EPP, and Scott may not be available to advise others
on how to extend EPP, so we should document some examples.  And I am not
implying that Scott should write this.  This document got some initial
support at the meeting, but it is probably too early to write this.

5) "Push" - There was to be a "push" document at one time.  It seems to
have been largely forgotten.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: [phone]                      Email: [e-mail]

Opinions expressed are property of my evil twin, not my employer.