Subject: [Ietf-not43] Status element in dreg

From: chris.ambler at enom.com (Chris Ambler)
Date: Wed Oct 15 22:38:02 2003

Well, we've got the standard RRP and EPP status flags, as well as any that a
registrar might care to add, if they're responding to the query. Indeed,
some status flags aren't mutually exclusive. Additionally, I can forsee
non-registry/non-registrar servers that have more, uncontemplated status
flags, some of which might even be internal (and, more than likely, additive
to other flags)

So if there were to be a <status> element, it might make sense to add an
attribute that describes from what realm the status derives, such as "epp"
or "rrp" or "podunk-registry-services" and the like, and to allow multiple
children.

Advanced codification of EPP and RRP status flags could be put into the XSD
with the note that more can be added at any time - or it could just be a
string value, with the known values documented for easy reference.

I'm all for localization, but in the case of EPP and RRP, the values have
codified meaning. In that case, we might want to have two fields, one for
the codified meaning and one for localized-for-display?

All off the top of my head, and without any prior knowledge of what has been
discussed in the past, so apologies if I'm treading on well-worn ground.

Christopher

-----Original Message-----
From: Andrew Newton
To: Chris Ambler
Cc: CRISP WG
Sent: 10/15/03 7:01 PM
Subject: Re: [Ietf-not43] Status element in dreg

Excellent question.

We've discussed this and it was on my list of items April mentioned. 
I'll refer you back to the original message on the topic:
http://lists.verisignlabs.com/pipermail/ietf-not43/2003-September/000890
.html

But to save time (since I had to go look it up anyway), here's the 
relevant part quoted:

>    Change the status codes in the following way:
> 1) They are contained within a <status> parent element.
> 2) Add a <transferPending> and <other> status values.
> 3) Allow the status elements to have an optional <description 
> language="xx"> child.
> 4) Make it a sequence and not a choice allowing the registry to define

> the mutual exclusion of status values.
> 
> This allows for localization as before but also accounts for locally 
> defined status values, and mixtures of status values.
> 

Also, if you believe registry-lock and registrar-lock or other values 
are common and not accounted for in the current schema, I think they 
should be added.

-andy

Chris Ambler wrote:
> Okay, specific to the protocol and apropos to the list (I hope).
> 
>  
> 
> I note that there are a fixed number of status elements allowable in a

> domain element, and none of them cover some of the more typical status

> possibilities like registry-lock, registrar-lock and the like. Is this

> deliberate? If so, is there a contemplated method for communicating 
> additional status information, such as the seeAlso element?
> 
>  
> 
> Christopher
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Oct 16 11:57:35 2003

I think what was proposed takes care of everything you just said, except 
for the new attribute for the realm.  That's a pretty good idea.  Should 
it be named 'realm' or 'origin'?

-andy