Would be great if we could get that to them by Fri, since once they have it, the ball is in their court for bottomsup schedule. thx, kevin

Bhuvan, please send the info to ctoomey ASAP. Thanks, Steve

We will be follwoing the PREG cookie format given below. It is picked from http://webcore/UREG2/preg_cookie.html. The additions that we have made are the fields PROFILENAME and PREG_DENIAL. Application will use this value to name the communicator profile (and a directory will also be created with the same name). PREG_DENIAL will be a check box, which becomes part of cookie NS_REG2_PREG only when the user checks on that checkbox indicating that he don't want to register. That info will be used later to let user to go browser pages directly (a default profile will be created for the user in this case). Other than that PREG cookie collects all required info like user's first and last names, email address and zip code (for sidebar) etc., Here is the basic information that you want. This should get you going with respect to what we are expecting from PREG cookie. I'm going to post a spec with all these details in a comprehensive fashion. Expected PREG Cookie format : NS_REG2_PREG=SHA1=<escaped sha1 hash>[-]FNAME=<user's first name>[-]LNAME=<user's last name>[-]EMAIL=<user's email address>[-]COUNTRY=<user's country>[-]POSTALCODE=<postal code>[-]LANGUAGE=<language code the user is using>[-]PROFILENAME=<user profile name>[-]PREG_DENIAL=<a check box and becomes part of NS_REG2_PREG only when it is checked> Steve, If you anything to add to the above, please update this bug report. I will pick up the changes and update the doc that I'm going to put together. Thanks. Bhuvan Adding ctoomey to the cc list. Also sending him the content via email.

We will be follwoing the PREG cookie format given below. It is picked from http://webcore/UREG2/preg_cookie.html. The additions that we have made are the fields PROFILENAME and PREG_DENIAL. Application will use this value to name the communicator profile (and a directory will also be created with the same name). PREG_DENIAL will be a check box, which becomes part of cookie NS_REG2_PREG only when the user checks on that checkbox indicating that he don't want to register. That info will be used later to let user to go browser pages directly (a default profile will be created for the user in this case). Other than that PREG cookie collects all required info like user's first and last names, email address and zip code (for sidebar) etc., Here is the basic information that you want. This should get you going with respect to what we are expecting from PREG cookie. I'm going to post a spec with all these details in a comprehensive fashion. Expected PREG Cookie format : NS_REG2_PREG=SHA1=<escaped sha1 hash>[-]FNAME=<user's first name>[-]LNAME=<user's last name>[-]EMAIL=<user's email address>[-]COUNTRY=<user's country>[-]POSTALCODE=<postal code>[-]LANGUAGE=<language code the user is using>[-]PROFILENAME=<user profile name>[-]PREG_DENIAL=<a check box and becomes part of NS_REG2_PREG only when it is checked> Steve, If you anything to add to the above, please update this bug report. I will pick up the changes and update the doc that I'm going to put together. Thanks. Bhuvan Sending the above info to We will be follwoing the PREG cookie format given below. It is picked from http://webcore/UREG2/preg_cookie.html. The additions that we have made are the fields PROFILENAME and PREG_DENIAL. Application will use this value to name the communicator profile (and a directory will also be created with the same name). PREG_DENIAL will be a check box, which becomes part of cookie NS_REG2_PREG only when the user checks on that checkbox indicating that he don't want to register. That info will be used later to let user to go browser pages directly (a default profile will be created for the user in this case). Other than that PREG cookie collects all required info like user's first and last names, email address and zip code (for sidebar) etc., Here is the basic information that you want. This should get you going with respect to what we are expecting from PREG cookie. I'm going to post a spec with all these details in a comprehensive fashion. Expected PREG Cookie format : NS_REG2_PREG=SHA1=<escaped sha1 hash>[-]FNAME=<user's first name>[-]LNAME=<user's last name>[-]EMAIL=<user's email address>[-]COUNTRY=<user's country>[-]POSTALCODE=<postal code>[-]LANGUAGE=<language code the user is using>[-]PROFILENAME=<user profile name>[-]PREG_DENIAL=<a check box and becomes part of NS_REG2_PREG only when it is checked> Steve, If you anything to add to the above, please update this bug report. I will pick up the changes and update the doc that I'm going to put together. Thanks. Bhuvan PS : I'm sending the above info to ctoomey via email.

This looks good. One change, one clarification, and one question One change: We'll be getting just one name, not first and last separately. One clarification: language country will be automatically set by NC to English - USA if the user did not hit the "international" button in Activation. in other words, if the user was not asked to enter his language/country, NC sets it as English/USA. One question: In Activation, we're pre-checking the box that says "remember my name/password on this computer". If they uncheck it, should this just be handled by the server (cookie expire at end of session) or do you have something in mind already? thx, kevin

I think the name and password thing should be handled by the server. Anyway, how are we doing it now for the current applications like webmail and all....? Storing the password in the cookie will be a bad thing again.

The "remember name/password on this computer" just means "do you want us to store a cookie that let's you login again easily/automatically". It's just a cookie question phrased in a way so that the user knows what benefit the user is deciding. Name/passwd won't be in the cookie itself. thx, kevin

dev bug

See http://webgroup/profmgr/specs/activation4.html for the latest writeup.